draft-ietf-imapext-2086upd-07.txt   draft-ietf-imapext-2086upd-08.txt 
Individual A. Melnikov Individual A. Melnikov
Internet-Draft Isode Ltd. Internet-Draft Isode Ltd.
Obsoletes: 2086 (if approved) June 12, 2005 Obsoletes: 2086 (if approved) June 27, 2005
Expires: December 14, 2005 Expires: December 29, 2005
IMAP4 ACL extension IMAP4 ACL extension
draft-ietf-imapext-2086upd-07 draft-ietf-imapext-2086upd-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 14, 2005. This Internet-Draft will expire on December 29, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
The ACL (Access Control List) extension (RFC 2086) of the Internet The ACL (Access Control List) extension (RFC 2086) of the Internet
Message Access Protocol (IMAP) permits mailbox access control lists Message Access Protocol (IMAP) permits mailbox access control lists
to be retrieved and manipulated through the IMAP protocol. to be retrieved and manipulated through the IMAP protocol.
skipping to change at page 3, line 29 skipping to change at page 3, line 29
3.7 LISTRIGHTS response . . . . . . . . . . . . . . . . . . . 12 3.7 LISTRIGHTS response . . . . . . . . . . . . . . . . . . . 12
3.8 MYRIGHTS response . . . . . . . . . . . . . . . . . . . . 13 3.8 MYRIGHTS response . . . . . . . . . . . . . . . . . . . . 13
4. Rights required to perform different IMAP4rev1 commands . . . 13 4. Rights required to perform different IMAP4rev1 commands . . . 13
5. Other considerations . . . . . . . . . . . . . . . . . . . . . 17 5. Other considerations . . . . . . . . . . . . . . . . . . . . . 17
5.1 Additional requirements and Implementation notes . . . . . 17 5.1 Additional requirements and Implementation notes . . . . . 17
5.1.1 Servers . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.1 Servers . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.2 Clients . . . . . . . . . . . . . . . . . . . . . . . 19 5.1.2 Clients . . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Mapping of ACL rights to READ-WRITE and READ-ONLY 5.2 Mapping of ACL rights to READ-WRITE and READ-ONLY
response codes . . . . . . . . . . . . . . . . . . . . . . 19 response codes . . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. Internationalization Considerations . . . . . . . . . . . . . 23 9. Internationalization Considerations . . . . . . . . . . . . . 24
A. Changes since RFC 2086 . . . . . . . . . . . . . . . . . . . . 23 A. Changes since RFC 2086 . . . . . . . . . . . . . . . . . . . . 24
B. Compatibility with RFC 2086 . . . . . . . . . . . . . . . . . 24 B. Compatibility with RFC 2086 . . . . . . . . . . . . . . . . . 25
C. Known deficiencies . . . . . . . . . . . . . . . . . . . . . . 24 C. Known deficiencies . . . . . . . . . . . . . . . . . . . . . . 25
D. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 D. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1 Normative References . . . . . . . . . . . . . . . . . . . 25 10.1 Normative References . . . . . . . . . . . . . . . . . . . 26
10.2 Informative References . . . . . . . . . . . . . . . . . . 26 10.2 Informative References . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 26 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . 28
1. Introduction and Overview 1. Introduction and Overview
The ACL (Access Control List) extension of the Internet Message The ACL (Access Control List) extension of the Internet Message
Access Protocol [IMAP4] permits mailbox access control lists to be Access Protocol [IMAP4] permits mailbox access control lists to be
retrieved and manipulated through the IMAP protocol. retrieved and manipulated through the IMAP protocol.
This document is a revision of RFC 2086 [RFC2086]. It tries to This document is a revision of RFC 2086 [RFC2086]. It tries to
clarify different ambiguities in RFC 2086, in particular use of UTF-8 clarify different ambiguities in RFC 2086, in particular use of UTF-8
[UTF-8] in identifiers, which rights are required for different IMAP4 [UTF-8] in access identifiers, which rights are required for
commands; how READ-WRITE/READ-ONLY response codes are related to ACL. different IMAP4 commands; how READ-WRITE/READ-ONLY response codes are
related to ACL.
2. Access Control 2. Access Control
The ACL extension is present in any IMAP4 implementation which The ACL extension is present in any IMAP4 implementation which
returns "ACL" as one of the supported capabilities to the CAPABILITY returns "ACL" as one of the supported capabilities to the CAPABILITY
command. command.
A server implementation conformant to this document MUST also return A server implementation conformant to this document MUST also return
rights (see below) not defined in Section 2.2 in the "RIGHTS=" rights (see below) not defined in Section 2.2 in the "RIGHTS="
capability. capability.
An access control list is a set of <identifier,rights> pairs. An ACL An access control list is a set of <access identifier,rights> pairs.
applies to a mailbox name. An ACL applies to a mailbox name.
Identifier is a UTF-8 [UTF-8] string. The identifier "anyone" is Access identifier (or just "identifier") is a UTF-8 [UTF-8] string.
reserved to refer to the universal identity (all authentications, The identifier "anyone" is reserved to refer to the universal
including anonymous). All user name strings accepted by the LOGIN or identity (all authentications, including anonymous). All user name
AUTHENTICATE commands to authenticate to the IMAP server are reserved strings accepted by the LOGIN or AUTHENTICATE commands to
as identifiers for the corresponding users. Identifiers starting authenticate to the IMAP server are reserved as identifiers for the
with a dash ("-") are reserved for "negative rights", described corresponding users. Identifiers starting with a dash ("-") are
below. All other identifier strings are interpreted in an reserved for "negative rights", described below. All other
implementation-defined manner. identifier strings are interpreted in an implementation-defined
manner.
Rights is a string listing a (possibly empty) set of alphanumeric Rights is a string listing a (possibly empty) set of alphanumeric
characters, each character listing a set of operations which is being characters, each character listing a set of operations which is being
controlled. Lowercase letters are reserved for "standard" rights, controlled. Lowercase letters are reserved for "standard" rights,
listed in Section 2.1. (Note that for compatibility with deployed listed in Section 2.1. (Note that for compatibility with deployed
clients and servers uppercase rights are not allowed). The set of clients and servers uppercase rights are not allowed). The set of
standard rights can only be extended by a standards-track document. standard rights can only be extended by a standards-track document.
Digits are reserved for implementation or site defined rights. Digits are reserved for implementation or site defined rights.
An implementation MAY tie rights together or MAY force rights to An implementation MAY tie rights together or MAY force rights to
skipping to change at page 9, line 24 skipping to change at page 9, line 24
digits ("0" .. "9"). digits ("0" .. "9").
3. Access control management commands and responses 3. Access control management commands and responses
Servers, when processing a command that has an identifier as a Servers, when processing a command that has an identifier as a
parameter (i.e. any of SETACL, DELETEACL and LISTRIGHTS commands), parameter (i.e. any of SETACL, DELETEACL and LISTRIGHTS commands),
SHOULD first prepare the received identifier using "SASLprep" profile SHOULD first prepare the received identifier using "SASLprep" profile
[SASLprep] of the "stringprep" algorithm [Stringprep]. If the [SASLprep] of the "stringprep" algorithm [Stringprep]. If the
preparation of the identifier fails or results in an empty string, preparation of the identifier fails or results in an empty string,
the server MUST refuse to perform the command with a BAD response. the server MUST refuse to perform the command with a BAD response.
Note that Section 6 recommends additional identifier's verification
steps.
3.1 SETACL command 3.1 SETACL command
Arguments: mailbox name Arguments: mailbox name
identifier identifier
access right modification access right modification
Data: no specific data for this command Data: no specific data for this command
Result: OK - setacl completed Result: OK - setacl completed
skipping to change at page 21, line 34 skipping to change at page 21, line 34
For example, when a user agent executes a GETACL command on a mailbox For example, when a user agent executes a GETACL command on a mailbox
that the user has no permission to LIST, the server would respond to that the user has no permission to LIST, the server would respond to
that request with the same error that would be used if the mailbox that request with the same error that would be used if the mailbox
did not exist, thus revealing no existence information, much less the did not exist, thus revealing no existence information, much less the
mailbox's ACL. mailbox's ACL.
IMAP clients implementing ACL that are able to modify ACLs SHOULD IMAP clients implementing ACL that are able to modify ACLs SHOULD
warn a user that wants to give full access (or even just the "a" warn a user that wants to give full access (or even just the "a"
right) to the special identifier "anyone". right) to the special identifier "anyone".
This document relies on [SASLprep] to describe steps required to
perform identifier canonicalization (preparation). The preparation
algorithm in SASLPrep was specifically designed such that its output
is canonical, and it is well-formed. However, due to an anomaly
[PR29] in the specification of Unicode normalization, canonical
equivalence is not guaranteed for a select few character sequences.
Identifiers prepared with SASLPrep can be stored and returned by an
ACL server. The anomaly affects ACL manipulation and evaluation of
identifiers containing the selected character sequences. These
sequences, however, do not appear in well-formed text. In order to
address this problem ACL server MAY reject identifiers containing
sequences described in [PR29] by sending the tagged BAD response.
This is in addition to the requirement to reject identifiers that
fail SASLPrep preparation as described in Section 3.
Other security considerations described in [IMAP4] are relevant to
this document. In particular, ACL information is sent in the clear
over the network unless confidentiality protection is negotiated.
This can be accomplished either by the use of STARTTLS, negotiated
privacy protection in the AUTHENTICATE command, or some other
protection mechanism.
7. Formal Syntax 7. Formal Syntax
Formal syntax is defined using ABNF [ABNF], extending the ABNF rules Formal syntax is defined using ABNF [ABNF], extending the ABNF rules
in section 9 of [IMAP4]. Elements not defined here can be found in in section 9 of [IMAP4]. Elements not defined here can be found in
the [ABNF] and [IMAP4]. the [ABNF] and [IMAP4].
Except as noted otherwise, all alphabetic characters are case- Except as noted otherwise, all alphabetic characters are case-
insensitive. The use of upper or lower case characters to define insensitive. The use of upper or lower case characters to define
token strings is for editorial clarity only. Implementations MUST token strings is for editorial clarity only. Implementations MUST
accept these strings in a case-insensitive fashion. accept these strings in a case-insensitive fashion.
skipping to change at page 26, line 10 skipping to change at page 27, line 10
December 2002. December 2002.
[SASLprep] [SASLprep]
Zeilenga, K., "SASLprep: Stringprep Profile for User Names Zeilenga, K., "SASLprep: Stringprep Profile for User Names
and Passwords", RFC 4013, February 2005. and Passwords", RFC 4013, February 2005.
10.2 Informative References 10.2 Informative References
[RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997. [RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.
[PR29] "Public Review Issue #29: Normalization Issue",
February 2004, <http://www.unicode.org/review/pr-29.html>.
Author's Address Author's Address
Alexey Melnikov Alexey Melnikov
Isode Ltd. Isode Ltd.
5 Castle Business Village 5 Castle Business Village
36 Station Road 36 Station Road
Hampton, Middlesex TW12 2BX Hampton, Middlesex TW12 2BX
GB GB
Email: alexey.melnikov@isode.com Email: alexey.melnikov@isode.com
 End of changes. 

This html diff was produced by rfcdiff 1.24, available from http://www.levkowetz.com/ietf/tools/rfcdiff/