WDIFF

draft-myers-imap-acl-00.txt --> draft-myers-imap-acl-01.txt

Network Working Group J. Myers
Internet Draft Carnegie Mellon
Document: draft-myers-imap-acl-00.txt December 1995 draft-myers-imap-acl-01.txt March 1996

IMAP4 ACL extension

Status of this Memo

This document is an Internet Draft. 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 a
``working draft'' or ``work in progress''.

To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
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. This document will
expire before April 1996. Distribution of this draft is unlimited.

J. Myers [Page i]

Internet DRAFT ACL December 14, 1995 March 21, 1996

1. Abstract

The ACL extension of the Internet Message Access Protocol [IMAP4]
permits access control lists to be manipulated through the IMAP
protocol.

2. Conventions Used in this Document

In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.

3. Introduction and Overview

The ACL extension is present in any IMAP4 implementation which
returns "ACL" as one of the supported capabilities to the CAPABILITY
command.

An access control list is a set of <identifier,rights> pairs.

Identifier is an ASCII string with implementation-defined semantics.
Possible variations of identifier interpretation include, but are not
limited to:

* User names, as specified in the LOGIN command.

* Named groups of users, presumably managed by some
authorization service.

* Only allowing identifiers supported by the operating system
(e.g. ``user'', ``group'', and ``other'' for the Unix filesystem)

* A prefix to the identifier specifying an "authentication
type".

As an example, an implementation may control posting to a group
based on the contents of the From: header:

from$user p

* Whether the union of rights for matching identifiers are granted
to a user or whether the rights for the most specific matching
identifier is granted.

As an example, for a mailbox with the following ACL:

user lrsa
group-user-is-in lrsw

J. Myers [Page 2]

Internet DRAFT ACL December 14, 1995 March 21, 1996

One implementation may grant the user 'lrswa' rights, another
may only grant the user 'lrsa' rights.

* A prefix to an identifier name specifying the listed rights
are to be removed from users who match the prefixed identifier.

As an example, for a mailbox with the following ACL:

group-user-is-in lrsw
-user w

An implementation may grant the user 'lrs' rights.

Rights is a string listing a (possibly empty) set of alphanumeric
characters, each character listing a set of operations which is being
controlled. Letters are reserved for ``standard'' rights, listed
below. Digits are reserved for implementation or site defined
rights. The standard rights are:

l - lookup (mailbox is visible to LIST/LSUB commands)
r - read (SELECT the mailbox, perform CHECK, FETCH, PARTIAL,
SEARCH, COPY from mailbox)
s - keep seen/unseen information across sessions (STORE \SEEN flag)
w - write (STORE flags other than \SEEN and \DELETED)
i - insert (perform APPEND, COPY into mailbox)
p - post (send mail to submission address for mailbox,
not enforced by IMAP4 itself)
c - create (CREATE new sub-mailboxes in any implementation-defined
hierarchy)
d - delete (STORE \DELETED flag, perform EXPUNGE)
a - administer (perform SETACL)

An implementation may tie rights together or may force rights to
always or never be granted. For example, in an implementation that
uses unix mode bits, the rights "wisd" are tied, the "a" right is
always granted to the owner and is never granted to another user. If
rights are tied in an implementation, it should be conservative in
granting rights in response to SETACL commands--unless all rights in
a tied set are specified, none should be used. Numeric rights may
not be tied.

J. Myers [Page 3]

Internet DRAFT ACL December 14, 1995 March 21, 1996

4. Commands

4.1. SETACL MAILBOX

Arguments: mailbox name
authentication identifier
access rights

Data: no specific data for this command

Result: OK - setacl mailbox completed
NO - setacl mailbox failure: can't set acl
BAD - command unknown or arguments invalid

The SETACL MAILBOX command changes the access control list on the
specified mailbox so that the specified identifier is granted the
permissions enumerated in rights.

4.2. DELETEACL MAILBOX

Arguments: mailbox name
authentication identifier

Data: no specific data for this command

Result: OK - deleteacl mailbox completed
NO - deleteacl mailbox failure: can't delete acl
BAD - command unknown or arguments invalid

Removes

The DELETEACL command removes any portion of the access control
list for mailbox for the specified identifier.

4.3. GETACL MAILBOX

Arguments: mailbox name

Data: untagged responses: ACL MAILBOX

Result: OK - getacl mailbox completed
NO - getacl mailbox failure: can't get acl
BAD - command unknown or arguments invalid

The GETACL MAILBOX command returns the access control list for mailbox in some set of untagged ACL replies. There may not be

J. Myers [Page 4]

Internet DRAFT ACL December 14, 1995

more than one March 21, 1996

an untagged ACL reply specifying any given identifier. reply.

Example: C: A002 GETACL MAILBOX INBOX
S: * ACL MAILBOX INBOX Fred rwipslda
S: A002 Ok OK Getacl complete

4.4. MYRIGHTS MAILBOX

Arguments: mailbox name

Data: untagged responses: MYRIGHTS MAILBOX

Result: OK - myrights mailbox completed
NO - myrights mailbox failure: can't get rights
BAD - command unknown or arguments invalid

Example: C: A003 MYRIGHTS INBOX
S: * MYRIGHTS INBOX rwipslda
S: A003 OK Myrights complete

The MYRIGHTS MAILBOX command returns the set of rights that the user has
to mailbox in an untagged MYRIGHTS reply.

5. Responses

5.1. ACL MAILBOX

Data: mailbox name
zero or more identifier rights pairs

The ACL MAILBOX response occurs as a result of a GETACL MAILBOX command. The
first string is the mailbox name for which this ACL entry applies. The second string
This is followed by zero or more pairs of strings, each pair
contains the identifier for which this the entry applies. The third string is applies followed by
the set of rights that the identifier has.

5.2. MYRIGHTS MAILBOX

Data: mailbox name
rights

The MYRIGHTS MAILBOX response occurs as a result of a MYRIGHTS
MAILBOX command.
The first string is the mailbox name for which this ACL entry
applies. The second string is the set of rights that the client
has.

J. Myers [Page 5]

Internet DRAFT ACL December 14, 1995 March 21, 1996

6. Formal Syntax

The following syntax specification uses the augmented Backus-Naur
Form (BNF) notation as specified in [RFC-822] with one exception; the
delimiter used with the "#" construct is a single space (SPACE) and as modified by [IMAP4].
Non-terminals referenced but not one or more commas. defined below are as defined by
[IMAP4].

Except as noted otherwise, all alphabetic characters are
case-insensitive. The use of upper or lower case characters to
define token strings is for editorial clarity only. Implementations
MUST accept these strings in a case-insensitive fashion.

acl_data ::= "ACL" SPACE acl_option SPACE astring SPACE astring mailbox *(SPACE identifier SPACE astring

acl_option ::= "MAILBOX" rights)

deleteacl ::= "DELETEACL" SPACE acl_option SPACE astring mailbox SPACE astring identifier

getacl ::= "GETACL" SPACE acl_option SPACE mailbox

identifier ::= astring

myrights ::= "MYRIGHTS" SPACE acl_option SPACE astring mailbox

myrights_data ::= "MYRIGHTS" acl_option SPACE astring mailbox SPACE rights

rights ::= astring

setacl ::= "SETACL" SPACE acl_option SPACE astring mailbox SPACE astring identifier SPACE astring rights

7. References

[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
RFC 1730, University of Washington, December 1994.

[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822.

8. Security Considerations

An implementation must make sure the ACL commands themselves do not
give information about mailboxes with appropriately restricted ACL's.
For example, a GETACL command on a mailbox for which the user has
insufficient rights should not admit the mailbox exists, much less
return the mailbox's ACL.

J. Myers [Page 6]

Internet DRAFT ACL December 14, 1995 March 21, 1996

9. Author's Address

John G. Myers
Carnegie-Mellon University
5000 Forbes Ave.
Pittsburgh PA, 15213-3890

Email: jgm+@cmu.edu

J. Myers [Page 7]

Internet DRAFT ACL December 14, 1995 March 21, 1996

Table of Contents

Status of this Memo ............................................... i
1. Abstract ..................................................... 2
2. Conventions Used in this Document ............................ 2
3. Introduction and Overview .................................... 2
4. Commands ..................................................... 4
4.1. SETACL MAILBOX ............................................... ....................................................... 4
4.2. DELETEACL MAILBOX ............................................ .................................................... 4
4.3. GETACL MAILBOX ............................................... ....................................................... 4
4.4. MYRIGHTS MAILBOX ............................................. ..................................................... 5
5. Responses .................................................... 5
5.1. ACL MAILBOX .................................................. .......................................................... 5
5.2. MYRIGHTS MAILBOX ............................................. ..................................................... 5
6. Formal Syntax ................................................ 6
7. References ................................................... 6
8. Security Considerations ...................................... 6
9. Author's Address ............................................. 7

J. Myers [Page ii]

----