IMAPEXT Working Group A. Melnikov Internet Draft Isode Ltd. Document: draft-melnikov-acl-rights-00.txt December 2004 Updates: 2086 Expires: June 2005 IMAP4 ACL extension - list of rights for various IMAP commands Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate 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. Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. Distribution of this draft is unlimited. Abstract This document lists Access Control rights (RFC 2086) required for various IMAP extensions. 1. Conventions Used in this Document 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 [KEYWORDS]. 2. Rights required to perform different IMAP commands Before executing a command an ACL compliant server must check which rights are required to perform it. This section groups command by functions they perform and list the rights required. It also gives the detailed description of any special processing required. For the purpose of this section the UID counterpart of a command is considered to be the same command, e.g. both UID COPY and COPY commands require the same set of rights. The tables listed in subsections of this section summarize different rights or their combinations that are required in order to perform different IMAP operations. As it is not always possible to express complex right checking and interactions, the description after the table should be used as the primary reference. All tables use the following legend: + - The right is required * - Only one of the rights marked with * is required (see description below) ? - The right is optional (see description below) "Any" - at least one of the "l", "r", "i", "c", "x", "a" rights is required "None" - No rights required to perform the command 2.1. Servers that also implement URLAUTH extension Servers that implement both [ACL] and the URLAUTH [URLAUTH] extensions MUST use the following table to check if the client is allowed to perform a particular IMAP command described in the URLAUTH document. The table uses the conventions defined in section 2. +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ | Operations\Rights | l | r | s | w | i | c | x | t | e | a | Any | None | +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ | RESETKEY | | + | | | | | | | | | | | | GENURLAUTH | | + | | | | | | | | | | | | URLFETCH | | | | | | | | | | | | + | +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ RESETKEY - "r" right is required for each mailbox affected by the command. In particular the RESETKEY MUST NOT reset keys on mailboxes that can't be SELECT/EXAMINEd by the current user. GENURLAUTH - "r" right is required for each mailbox referenced in the URL(s) specified as parameter(s) to the GENURLAUTH command. URLFETCH - no rights required to perform this operation. 2.2. Servers that also implement CATENATE extension Servers that implement both [ACL] and the [CATENATE] extensions MUST use the following table to check if the client is allowed to perform a particular IMAP command described in the CATENATE document. The table uses the conventions defined in section 2. +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ | Operations\Rights | l | r | s | w | i | c | x | t | e | a | Any | None | +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ | CATENATE | | | ? | ? | + | | | ? | | | | | +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ CATENATE command obey the same set of access control rules as the APPEND command. The rules are summarized in this section. Before performing a CATENATE command the server MUST check if the user has the "i" right for the target mailbox. If the user doesn't have the "i" right, the operation fails. Otherwise for each catenated message the server MUST check if the user has "t" right - when the message has \Deleted flag set "s" right - when the message has \Seen flag set "w" right for all other message flags. Only when the user has a particular right the corresponding flags are stored for the newly created message. The server MUST NOT fail a CATENATE if the user has no rights to set a particular flag. 3. Security Considerations <<TBD>> 4. IANA Considerations This document doesn't have any IANA considerations. 5. References 5.1. Normative References [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, November 1997. [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, University of Washington, March 2003. [ACL] Melnikov, A., "IMAP4 ACL extension", work in progress, draft-ietf-imapext-2086upd-XX.txt. [URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", work in progress, draft-ietf-lemonade-urlauth-XX.txt [CATENATE] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", work in progress, draft-ietf-lemonade-catenate-XX.txt 6. Acknowledgment Editor appreciates comments received from Mark Crispin and other participants of the IMAPEXT working group. 7. Editor's Address Alexey Melnikov email: alexey.melnikov@isode.com Isode Limited 8. IPR Disclosure Acknowledgement By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 9. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 10. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.