draft-ietf-extra-imap-unauth-01.txt   rfc8437.txt 
Network Working Group C. Newman Internet Engineering Task Force (IETF) C. Newman
Internet-Draft Oracle Request for Comments: 8437 Oracle
Updates: 3501 (if approved) June 7, 2018 Updates: 3501 August 2018
Intended status: Standards Track Category: Standards Track
Expires: December 9, 2018 ISSN: 2070-1721
IMAP UNAUTHENTICATE for Connection Reuse IMAP UNAUTHENTICATE Extension for Connection Reuse
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 is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on December 9, 2018. 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 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 12 skipping to change at page 2, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 2
3. UNAUTHENTICATE Command . . . . . . . . . . . . . . . . . . . 3 3. UNAUTHENTICATE Command . . . . . . . . . . . . . . . . . . . 3
4. Interactions . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Interactions . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Stateful Extensions . . . . . . . . . . . . . . . . . . . 4 4.1. Stateful Extensions . . . . . . . . . . . . . . . . . . . 4
4.2. Client Certificates, SASL EXTERNAL and imaps . . . . . . 5 4.2. Client Certificates, SASL EXTERNAL, and imaps . . . . . . 5
5. Revised State Machine . . . . . . . . . . . . . . . . . . . . 5 5. Revised State Machine . . . . . . . . . . . . . . . . . . . . 6
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Design Considerations . . . . . . . . . . . . . . . 10 Appendix A. Design Considerations . . . . . . . . . . . . . . . 11
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Modern IMAP [RFC3501] server deployments often have peer systems with Modern IMAP [RFC3501] server deployments often have peer systems with
administrative privilege that perform actions on behalf of IMAP end- administrative privilege that perform actions on behalf of IMAP end
users. For example, a voice mail gateway can use IMAP to store a users. For example, a voicemail gateway can use IMAP to store a
user's voicemail and mark that voicemail as \Seen when the user user's voicemail and mark that voicemail as \Seen when the user
listens to it via the phone interface. These systems can issue the listens to it via the phone interface. These systems can issue the
IMAP AUTHENTICATE command with administrative credentials to act on IMAP AUTHENTICATE command with administrative credentials to act on
behalf of other users. However, with the IMAP base specification, behalf of other users. However, with the IMAP base specification,
these specialized IMAP clients must close the connection and create a these specialized IMAP clients must close the connection and create a
new connection for each user. For efficiency reasons, it is new connection for each user. For efficiency reasons, it is
desirable for these clients to reuse the same connection, desirable for these clients to reuse the same connection,
particularly if SSL has been negotiated. This specification proposes particularly if SSL has been negotiated. This specification proposes
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 this
from authenticated or selected state to not authenticated state. transition.
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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. 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 [RFC5246] layer. Upon completion, the server for the state of the TLS [RFC8446] layer. Upon completion, the
connection is placed in not authenticated state. This represents server connection is placed in not authenticated state. This
transition 7 in the State Machine Diagram (Section 5). represents 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 Simple Authentication and Security
active, the server terminates its outgoing security layer immediately Layer (SASL) [RFC4422] was active, the server terminates its outgoing
after sending the CRLF following the OK response. The client's security layer immediately after sending the CRLF following the OK
outgoing security layer terminates immediately after the CRLF response. The client's outgoing security layer terminates
following the UNAUTHENTICATE command. Note that a BAD response only immediately after the CRLF following the UNAUTHENTICATE command.
occurs if UNAUTHENTICATE is issued in an invalid state, is not Note that a BAD response only occurs if UNAUTHENTICATE is issued in
advertised by the server, or does not follow the command syntax in an invalid state, is not advertised by the server, or does not follow
the specification, and a NO response is not permitted. As a result, the command syntax in the specification. A NO response is not
specification-compliant implementations will interoperate across permitted. As a result, specification-compliant implementations will
security layer termination. 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 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 may 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
and caching it for the duration of the client connection can be way, 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 defined by the implementation.
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
The connection state for the following list of IMAP extensions 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 a) the specified extension is advertised and b) 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 the connection state applies to
current and future extensions except STARTTLS and ID. Additional all current and future extensions except STARTTLS and ID. Additional
requirements apply to specific stateful extensions as follows: requirements apply to specific stateful extensions as follows:
o Cached identity information, such a group memberships, that are o Cached identity information, such as 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 After an UNAUTHENTICATE command is issued, CONDSTORE servers
enabling command had been issued after an UNAUTHENTICATE command [RFC7162] MUST behave as if no CONDSTORE-enabling command was
is issued. issued.
o If IMAP COMPRESS [RFC4978] is active, the server terminates its o If IMAP COMPRESS [RFC4978] is active, the server terminates its
outgoing compression layer after it sends the CRLF following the outgoing compression layer after it sends the CRLF following the
OK response. The client terminates its outgoing compression layer OK response. The client terminates its outgoing compression layer
after the CRLF following the UNAUTHENTICATE command. In the event after the CRLF following the UNAUTHENTICATE command. When it
it matters, the compression layer terminates before a SASL layer matters, the compression layer terminates before a SASL layer
terminates. 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.
o A server advertising LANGUAGE [RFC5255] will revert to the o A server advertising LANGUAGE [RFC5255] will revert to the
"i-default" language. "i-default" language.
o When a server advertises CONTEXT=SEARCH or CONTEXT=SORT [RFC5267], o When a server advertises CONTEXT=SEARCH or CONTEXT=SORT [RFC5267],
the UNAUTHENTICATE command includes an implicit CANCELUPDATE for the UNAUTHENTICATE command includes an implicit CANCELUPDATE for
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 the 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 [RFC8446] security layer is negotiated using either the
STARTTLS command or use of the imaps port [RFC8314], IMAP servers may STARTTLS command or the imaps port [RFC8314], IMAP servers may be
be configured to request a client certificate and IMAP clients may 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; however, they do have an impact when
mechanism [RFC4422] in an IMAP AUTHENTICATE command that directs the the SASL EXTERNAL mechanism [RFC4422] in an IMAP AUTHENTICATE command
server to use the provided client certificate to authenticate as the is used to direct the server to use the provided client certificate
specified IMAP user. The UNAUTHENTICATE command breaks any to authenticate as the specified IMAP user. The UNAUTHENTICATE
application-level binding of the TLS client credentials but does not command breaks any application-level binding of the TLS client
discard the client credentials. As a result, an administrative credentials but does not discard the client credentials. As a
client may use a client certificate with administrative privilege to result, an administrative client may use a client certificate with
act on behalf of multiple IMAP users in the same connection via the administrative privilege to act on behalf of multiple IMAP users in
EXTERNAL mechanism and the UNAUTHENTICATE command. the same connection via the EXTERNAL mechanism and the UNAUTHENTICATE
command.
Some server implementations using the imaps port will request and use Some server implementations using the imaps port will request and use
a TLS client certificate to authenticate immediately as the default a TLS client certificate to authenticate immediately as the default
IMAP identity associated with that certificate. These IMAP identity associated with that certificate. These
implementations indicate this behavior by using the PREAUTH greeting implementations indicate this behavior by using the PREAUTH greeting,
as indicated by transition 2 in the State Machine Diagram as indicated by Transition 2 in the State Machine Diagram
(Section 5). As a result, TLS client certificates can not be used (Section 5). As a result, TLS client certificates cannot be used for
for administrative proxy authentication with the imaps port unless administrative proxy authentication with the imaps port unless the
the UNAUTHENTICATE command is also advertised. In that case, an UNAUTHENTICATE command is also advertised. In that case, an
administrative client can respond to the PREAUTH greeting with an administrative client can respond to the PREAUTH greeting with an
UNAUTHENTICATE command and then issue an AUTHENTICATE EXTERNAL UNAUTHENTICATE command and then issue an AUTHENTICATE EXTERNAL
command. command.
5. Revised State Machine 5. Revised State Machine
+----------------------+ +----------------------+
|connection established| |connection established|
+----------------------+ +----------------------+
|| ||
\/ \/
+--------------------------------------+ +--------------------------------------+
| server greeting | | server greeting |
+--------------------------------------+ +--------------------------------------+
|| (1) || (2) || (3) || (1) || (2) || (3)
\/ || || \/ || ||
skipping to change at page 6, line 42 skipping to change at page 6, line 45
| Logout | | Logout |
+--------------------------------------+ +--------------------------------------+
|| ||
\/ \/
+-------------------------------+ +-------------------------------+
|both sides close the connection| |both sides close the connection|
+-------------------------------+ +-------------------------------+
Revised IMAP state machine transitions: Revised IMAP state machine transitions:
1. connection without pre-authentication (OK greeting) 1. Connection without pre-authentication (OK greeting)
2. pre-authenticated connection (PREAUTH greeting) 2. Pre-authenticated connection (PREAUTH greeting)
3. rejected connection (BYE greeting) 3. Rejected connection (BYE greeting)
4. successful LOGIN or AUTHENTICATE command 4. Successful LOGIN or AUTHENTICATE command
5. Successful SELECT or EXAMINE command
5. successful SELECT or EXAMINE command 6. CLOSE, UNSELECT [RFC3691], or failed SELECT or EXAMINE command
6. CLOSE, UNSELECT [RFC3691] or failed SELECT or EXAMINE command
7. UNAUTHENTICATE command 7. UNAUTHENTICATE command
8. LOGOUT command, server shutdown, or connection closed 8. LOGOUT command, server shutdown, or connection closed
6. Formal Syntax 6. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) as described in [RFC5234]. Amended terms are defined in Form (ABNF), as described in [RFC5234]. Amended terms are defined in
[RFC3501]. [RFC3501].
capability =/ "UNAUTHENTICATE" capability =/ "UNAUTHENTICATE"
command-auth =/ "UNAUTHENTICATE" command-auth =/ "UNAUTHENTICATE"
command-select =/ "UNAUTHENTICATE" command-select =/ "UNAUTHENTICATE"
7. IANA Considerations 7. IANA Considerations
The IANA shall add the UNAUTHENTICATE capability to the IMAP4 IANA has added the UNAUTHENTICATE capability to the "IMAP
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 in which 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 once 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. This
extension is appropriate for some deployments but may not be extension is therefore appropriate for some deployments but may not
appropriate for the most security sensitive environments. be 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
subsequent user does not inherit any data or privileges from the subsequent user does not inherit any data or privileges from the
previous user. State data associated with a user can include cached previous user. State data associated with a user can include cached
identity information such as group membership used to evaluate access identity information such as group membership used to evaluate access
control lists [RFC4314], active notifications [RFC5465], access to control lists [RFC4314], active notifications [RFC5465], access to
per-user data such as flags, etc. per-user data such as flags, etc.
IMAP server systems are often deployed in a two-tier model where a IMAP server systems are often deployed in a two-tier model where a
server-side IMAP proxy routes to an IMAP back-end which handles all server-side IMAP proxy routes to an IMAP backend that handles all
connections for a subset of possible users. Some IMAP proxies enter connections for a subset of possible users. Some IMAP proxies enter
a pass-through mode after authentication. The UNAUTHENTICATE a pass-through mode after authentication. If enabled, the
command, if enabled, would allow a client to bypass any security UNAUTHENTICATE command would allow a client, on a subsequent
restrictions present in the proxy layer but not in the back-end authentication, to bypass any security restrictions present in the
server layer on a subsequent authentication. As a result, IMAP proxy layer but not in the backend server layer. As a result, IMAP
server implementations of this extension MUST provide a way to server implementations of this extension MUST provide a way to
disable it when it is not needed. Use of an IMAP proxy that disable it when it is not needed. Use of an IMAP proxy that
processes the UNAUTHENTICATE command at the proxy layer eliminates processes the UNAUTHENTICATE command at the proxy layer eliminates
this concern. Another option to mitigate this concern is for servers this concern. Another option to mitigate this concern is for servers
to only enable the UNAUTHENTICATE extension if the supplied to only enable the UNAUTHENTICATE extension if the supplied
authentication credentials were associated with an administrative authentication credentials are associated with an administrative
identity. identity.
9. Privacy Considerations 9. Privacy Considerations
For the most part, this extension will have no impact on the privacy For the most part, this extension will have no impact on the privacy
considerations already present in an IMAP implementation. However, considerations already present in an IMAP implementation. However,
if this extension were used between data centers, it could improve if this extension were used between data centers, it could improve
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 reuse.
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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 9, line 35 skipping to change at page 9, line 41
<https://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, <https://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, <https://www.rfc-editor.org/info/rfc5182>. 2008, <https://www.rfc-editor.org/info/rfc5182>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<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,
<https://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,
<https://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,
skipping to change at page 10, line 24 skipping to change at page 10, line 28
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,
<https://www.rfc-editor.org/info/rfc7162>. <https://www.rfc-editor.org/info/rfc7162>.
[RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete: [RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete:
Use of Transport Layer Security (TLS) for Email Submission Use of Transport Layer Security (TLS) for Email Submission
and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018,
<https://www.rfc-editor.org/info/rfc8314>. <https://www.rfc-editor.org/info/rfc8314>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
Appendix A. Design Considerations Appendix A. Design Considerations
The author deliberately choose to add a separate UNAUTHENTICATE The author deliberately chose 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 The primary reason for this choice is that the code that transitions
transitions from not authenticated state to authenticated state in a from not authenticated state to authenticated state in a server is
server is often the most security sensitive code as it needs to often the most security-sensitive code, because it needs to assume
assume and handle unconditionally hostile attackers. That sensitive and handle unconditionally hostile attackers. That sensitive code is
code is simpler if it only handles a single server state simpler if it only handles a single server state (unauthenticated)
(unauthenticated) and the state transition is as simple as possible. and the state transition is as simple as possible. Smaller and
Smaller and simpler code is easier to audit and write in a secure simpler code is easier to audit and write in a secure way.
way.
A secondary reason to have a separate command is that it is simpler A secondary reason to have a separate command is that it is simpler
to enable or disable the feature with that design. See the to enable or disable the feature with that design. See the
discussion in the security considerations section recommending discussion in the Security Considerations section recommending that
implementations provide a way to disable this extension. implementations provide a way to disable this extension.
Appendix B. Acknowledgements Acknowledgements
Thanks to Fred Batty for implementing UNAUTHENTICATE, and to Cyrus Thanks to Fred Batty for implementing UNAUTHENTICATE and to Cyrus
Daboo for constructive suggestions to improve this draft. Daboo for constructive suggestions to improve this document.
Author's Address Author's Address
Chris Newman Chris Newman
Oracle Oracle
440 E. Huntington Dr., Suite 400 440 E. Huntington Dr., Suite 400
Arcadia, CA 91006 Arcadia, CA 91006
US United States of America
Email: chris.newman@oracle.com Email: chris.newman@oracle.com
 End of changes. 52 change blocks. 
124 lines changed or deleted 121 lines changed or added

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