Network Working Group X. Jia Internet Draft China Unicom Intended status: Proposed Standard June 13, 2011 Expires: December 2011 IMAP4 Multi-Account Authentication draft-jia-imap-multiaccount-authentication-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 13, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract Jia Expires December 13, 2011 [Page 1] Internet-Draft IMAP4 Multi-Account Authentication June 2011 Simultaneous authentication for multiple accounts is an attractive feature but is not supported in the current Internet Message Access Protocol [RFC3501]. This document introduces an extension of the Internet Message Access Protocol, Version 4rev1 (IMAP4rev1). With this extension, when a client is authenticated with one of its account identifiers, it is also authenticated automatically with all the other associated account identifiers (if present), i.e., a client can be authenticated for all of its associated accounts at the same time. Table of Contents 1. Introduction ................................................. 2 2. Conventions used in this document ............................ 2 3. Specification ................................................ 3 4. Security Considerations ...................................... 3 5. IANA Considerations .......................................... 3 6. References ................................................... 3 7. Acknowledgments .............................................. 3 1. Introduction Nowadays, it's quite common for a user to have multiple email accounts. However, according to the current IMAP4rev1 protocol [RFC3501], if a user needs to access an account after he/she has been authenticated for a different one, he/she has to first log out of the current account and then be re-authenticated for the desired account. Thus, a user may find it inconvenient to exchange information among his/her multiple email accounts. For the sake of a better user experience, this document introduces an extension of the IMAP4rev1 protocol. With this extension, a user can have multiple email accounts associated with each other. Furthermore, once the user's email client is successfully authenticated with the identifier of one of the user's accounts, the identifiers of the other associated accounts will also be in authenticated states. 2. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Jia Expires December 13, 2011 [Page 2] Internet-Draft IMAP4 Multi-Account Authentication June 2011 In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. 3. Specification A user's registration profile SHOULD indicate the association of the user's multiple account identifiers, as requested by the user. During the authentication process initiated by a client's AUTHENTICATE or LOGIN command, the server SHOULD check that client's registration profile to find out whether or not there are any other account identifiers associated with the one provided in the client's authentication request. In the case where the client's registration profile indicates the association of multiple account identifiers, once the client is successfully authenticated with the account identifier provided in the client's authentication request, the client SHOULD also pass the authentication automatically for all those associated account identifiers listed in the registration profile. In one word, a successful authentication for a single account identifier brings all the associated account identifiers into the authenticated states. 4. Security Considerations There are no known security issues with this extension. 5. IANA Considerations 6. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3501] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003. 7. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Jia Expires December 13, 2011 [Page 3] Internet-Draft IMAP4 Multi-Account Authentication June 2011 Authors' Addresses Xiongwei Jia China Unicom Research Institute Email: jiaxw9@chinaunicom.cn Yan LU ZTE Corporation 68 Zijinghua Road, Nanjing, China 210012 Email: luyan@zte.com.cn Xin DING ZTE Corporation 68 Zijinghua Road, Nanjing, China 210012 Email: ding.xin@zte.com.cn Jerry Shih AT&T Email: jerry.shih@ATT.COM Jia Expires December 13, 2011 [Page 4]