Internet Message Access Protocol (IMAP) - URLAUTH Extension
RFC 4467
|
| Document |
Type |
|
RFC - Proposed Standard
(May 2006; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4467 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Ted Hardie
|
|
Send notices to |
|
(None)
|
Network Working Group M. Crispin
Request for Comments: 4467 University of Washington
Updates: 3501 May 2006
Category: Standards Track
Internet Message Access Protocol (IMAP) - URLAUTH Extension
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes the URLAUTH extension to the Internet Message
Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL)
(RFC 2192). This extension provides a means by which an IMAP client
can use URLs carrying authorization to access limited message data on
the IMAP server.
An IMAP server that supports this extension indicates this with a
capability name of "URLAUTH".
1. Introduction
In [IMAPURL], a URL of the form imap://fred@example.com/INBOX/;uid=20
requires authorization as userid "fred". However, [IMAPURL] implies
that it only supports authentication and confuses the concepts of
authentication and authorization.
The URLAUTH extension defines an authorization mechanism for IMAP
URLs to replace [IMAPURL]'s authentication-only mechanism. URLAUTH
conveys authorization in the URL string itself and reuses a portion
of the syntax of the [IMAPURL] authentication mechanism to convey the
authorization identity (which also defines the default namespace in
[IMAP]).
The URLAUTH extension provides a means by which an authorized user of
an IMAP server can create URLAUTH-authorized IMAP URLs. A URLAUTH-
authorized URL conveys authorization (not authentication) to the data
Crispin Standards Track [Page 1]
RFC 4467 IMAP - URLAUTH Extension May 2006
addressed by that URL. This URL can be used in another IMAP session
to access specific content on the IMAP server, without otherwise
providing authorization to any other data (such as other data in the
mailbox specified in the URL) owned by the authorizing user.
Conceptually, a URLAUTH-authorized URL can be thought of as a "pawn
ticket" that carries no authentication information and can be
redeemed by whomever presents it. However, unlike a pawn ticket,
URLAUTH has optional mechanisms to restrict the usage of a URLAUTH-
authorized URL. Using these mechanisms, URLAUTH-authorized URLs can
be usable by:
. anonymous (the "pawn ticket" model)
. authenticated users only
. a specific authenticated user only
. message submission acting on behalf of a specific user only
There is also a mechanism for expiration.
A URLAUTH-authorized URL can be used in the argument to the BURL
command in message composition, as described in [BURL], for such
purposes as allowing a client (with limited memory or other
resources) to submit a message forward or to resend from an IMAP
mailbox without requiring the client to fetch that message data.
The URLAUTH is generated using an authorization mechanism name and an
authorization token, which is generated using a secret mailbox access
key. An IMAP client can request that the server generate and assign
a new mailbox access key (thus effectively revoking all current URLs
using URLAUTH with the old mailbox access key) but cannot set the
mailbox access key to a key of its own choosing.
1.1. Conventions Used in this Document
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as defined in [KEYWORDS].
The formal syntax uses the Augmented Backus-Naur Form (ABNF) notation
including the core rules defined in Appendix A of [ABNF].
In examples, "C:" and "S:" indicate lines sent by the client and
server, respectively. If a single "C:" or "S:" label applies to
multiple lines, then the line breaks between those lines are for
editorial clarity only and are not part of the actual protocol
exchange.
Crispin Standards Track [Page 2]
RFC 4467 IMAP - URLAUTH Extension May 2006
2. Concepts
2.1. URLAUTH
Show full document text