rfc4467.txt

广泛使用的邮件服务器！同时

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://[e-mail]/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

   The URLAUTH is a component, appended at the end of a URL, that
   conveys authorization to access the data addressed by that URL.  It
   contains an authorized access identifier, an authorization mechanism
   name, and an authorization token.  The authorization token is
   generated from the URL, the authorized access identifier, the
   authorization mechanism name, and a mailbox access key.

2.2.  Mailbox Access Key

   The mailbox access key is a random string with at least 128 bits of
   entropy.  It is generated by software (not by the human user) and
   MUST be unpredictable.

   Each user has a table of mailboxes and an associated mailbox access
   key for each mailbox.  Consequently, the mailbox access key is per-
   user and per-mailbox.  In other words, two users sharing the same
   mailbox each have a different mailbox access key for that mailbox,
   and each mailbox accessed by a single user also has a different
   mailbox access key.

2.3.  Authorized Access Identifier

   The authorized access identifier restricts use of the URLAUTH
   authorized URL to certain users authorized on the server, as
   described in section 3.

2.4.  Authorization Mechanism

   The authorization mechanism is the algorithm by which the URLAUTH is
   generated and subsequently verified, using the mailbox access key.

2.4.1.  INTERNAL Authorization Mechanism

   This specification defines the INTERNAL mechanism, which uses a token
   generation algorithm of the server's choosing and does not involve
   disclosure of the mailbox access key to the client.

      Note: The token generation algorithm chosen by the server
      implementation should be modern and reasonably secure.  At the
      time of the writing of this document, an [HMAC] such as HMAC-SHA1
      is recommended.






Crispin                     Standards Track                     [Page 3]

RFC 4467                IMAP - URLAUTH Extension                May 2006


      If it becomes necessary to change the token generation algorithm
      of the INTERNAL mechanism (e.g., because an attack against the
      current algorithm has been discovered), all currently existing
      URLAUTH-authorized URLs are invalidated by the change in
      algorithm.  Since this would be an unpleasant surprise to
      applications that depend upon the validity of a URLAUTH-authorized
      URL, and there is no good way to do a bulk update of existing
      deployed URLs, it is best to avoid this situation by using a
      secure algorithm as opposed to one that is "good enough".

      Server implementations SHOULD consider the possibility of changing
      the algorithm.  In some cases, it may be desirable to implement
      the change of algorithm in a way that newly-generated tokens use
      the new algorithm, but that for a limited period of time tokens
      using either the new or old algorithm can be validated.
      Consequently, the server SHOULD incorporate some means of
      identifying the token generation algorithm within the token.

   Although this specification is extensible for other mechanisms, none
   are defined in this document.  In addition to the mechanism name
   itself, other mechanisms may have mechanism-specific data, which is
   to be interpreted according to the definition of that mechanism.

2.5.  Authorization Token

   The authorization token is a deterministic string of at least 128
   bits that an entity with knowledge of the secret mailbox access key
   and URL authorization mechanism can use to verify the URL.

3.  IMAP URL Extensions

   [IMAPURL] is extended by allowing the addition of
   ";EXPIRE=<datetime>" and ";URLAUTH=<access>:<mech>:<token>" to IMAP
   URLs that refer to a specific message or message parts.

   The URLAUTH is comprised of ";URLAUTH=<access>:<mech>:<token>" and
   MUST be at the end of the URL.

   URLAUTH does not apply to, and MUST NOT be used with, any IMAP URL
   that refers to an entire IMAP server, a list of mailboxes, an entire
   IMAP mailbox, or IMAP search results.

   When ";EXPIRE=<datetime>" is used, this indicates the latest date and
   time that the URL is valid.  After that date and time, the URL has
   expired, and server implementations MUST reject the URL.  If
   ";EXPIRE=<datetime>" is not used, the URL has no expiration, but
   still can be revoked as discussed below.




Crispin                     Standards Track                     [Page 4]

RFC 4467                IMAP - URLAUTH Extension                May 2006


   The URLAUTH takes the form ";URLAUTH=<access>:<mech>:<token>".  It is
   composed of three parts.  The <access> portion provides the
   authorized access identifiers, which may constrain the operations and
   users that are permitted to use this URL.  The <mech> portion
   provides the authorization mechanism used by the IMAP server to
   generate the authorization token that follows.  The <token> portion
   provides the authorization token.

   The "submit+" access identifier prefix, followed by a userid,
   indicates that only a userid authorized as a message submission
   entity on behalf of the specified userid is permitted to use this
   URL.  The IMAP server does not validate the specified userid but does
   validate that the IMAP session has an authorization identity that is
   authorized as a message submission entity.  The authorized message
   submission entity MUST validate the userid prior to contacting the
   IMAP server.

   The "user+" access identifier prefix, followed by a userid, indicates
   that use of this URL is limited to IMAP sessions that are logged in
   as the specified userid (that is, have authorization identity as that
   userid).

      Note: If a SASL mechanism that provides both authorization and
      authentication identifiers is used to authenticate to the IMAP
      server, the "user+" access identifier MUST match the authorization
      identifier.

   The "authuser" access identifier indicates that use of this URL is
   limited to IMAP sessions that are logged in as an authorized user
   (that is, have authorization identity as an authorized user) of that
   IMAP server.  Use of this URL is prohibited to anonymous IMAP
   sessions.

   The "anonymous" access identifier indicates that use of this URL is
   not restricted by session authorization identity; that is, any IMAP
   session in authenticated or selected state (as defined in [IMAP]),
   including anonymous sessions, may issue a URLFETCH using this URL.

   The authorization token is represented as an ASCII-encoded
   hexadecimal string, which is used to authorize the URL.  The length
   and the calculation of the authorization token depends upon the
   mechanism used; but, in all cases, the authorization token is at
   least 128 bits (and therefore at least 32 hexadecimal digits).








Crispin                     Standards Track                     [Page 5]

RFC 4467                IMAP - URLAUTH Extension                May 2006


4.  Discussion of URLAUTH Authorization Issues

   In [IMAPURL], the userid before the "@" in the URL has two purposes:

      1) It provides context for user-specific mailbox paths such as
         "INBOX".

      2) It specifies that resolution of the URL requires logging in as
         that user and limits use of that URL to only that user.

   An obvious limitation of using the same field for both purposes is
   that the URL can only be resolved by the mailbox owner.

   URLAUTH overrides the second purpose of the userid in the IMAP URL
   and by default permits the URL to be resolved by any user permitted
   by the access identifier.

   The "user+<userid>" access identifier limits resolution of that URL
   to a particular userid, whereas the "submit+<userid>" access
   identifier is more general and simply requires that the session be
   authorized by a user that has been granted a "submit" role within the
   authentication system.  Use of either of these access identifiers
   makes it impossible for an attacker, spying on the session, to use
   the same URL, either directly or by submission to a message
   submission entity.

   The "authuser" and "anonymous" access identifiers do not have this
   level of protection and should be used with caution.  These access
   identifiers are primarily useful for public export of data from an
   IMAP server, without requiring that it be copied to a web or
   anonymous FTP server.  Refer to the Security Considerations for more
   details.

5.  Generation of URLAUTH-Authorized URLs

   A URLAUTH-authorized URL is generated from an initial URL as follows:

   An initial URL is built, ending with ";URLAUTH=<access>" but without
   the ":<mech>:<token>" components.  An authorization mechanism is
   selected and used to calculate the authorization token, with the
   initial URL as the data and a secret known to the IMAP server as the
   key.  The URLAUTH-authorized URL is generated by taking the initial
   URL and appending ":", the URL authorization mechanism name, ":", and
   the ASCII-encoded hexadecimal representation of the authorization
   token.






Crispin                     Standards Track                     [Page 6]