Internet DRAFT - draft-melnikov-acl-rights
draft-melnikov-acl-rights
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.
