rfc4467.txt

来自「广泛使用的邮件服务器！同时」· 文本 代码 · 共 1,012 行 · 第 1/3 页


RFC 4467                IMAP - URLAUTH Extension                May 2006


      Note: ASCII-encoded hexadecimal is used instead of BASE64 because
      a BASE64 representation may have "=" padding characters, which
      would be problematic in a URL.

   In the INTERNAL mechanism, the mailbox access key for that mailbox is
   the secret known to the IMAP server, and a server-selected algorithm
   is used as described in section 2.4.1.

6.  Validation of URLAUTH-authorized URLs

   A URLAUTH-authorized URL is validated as follows:

   The URL is split at the ":" that separates "<access>" from
   "<mech>:<token>" in the ";URLAUTH=<access>:<mech>:<token>" portion of
   the URL.  The "<mech>:<token>" portion is first parsed and saved as
   the authorization mechanism and the authorization token.  The URL is
   truncated, discarding the ":" described above, to create a "rump URL"
   (the URL minus the ":" and the "<mech>:<token>" portion).  The rump
   URL is then analyzed to identify the mailbox.

   If the mailbox cannot be identified, an authorization token is
   calculated on the rump URL, using random "plausible" keys (selected
   by the server) as needed, before returning a validation failure.
   This prevents timing attacks aimed at identifying mailbox names.

   If the mailbox can be identified, the authorization token is
   calculated on the rump URL and a secret known to the IMAP server
   using the given URL authorization mechanism.  Validation is
   successful if, and only if, the calculated authorization token for
   that mechanism matches the authorization token supplied in
   ";URLAUTH=<access>:<mech>:<token>".

   Removal of the ":<mech>:<token>" portion of the URL MUST be the only
   operation applied to the URLAUTH-authorized URL to get the rump URL.
   In particular, URL percent escape decoding and case-folding
   (including to the domain part of the URL) MUST NOT occur.

   In the INTERNAL mechanism, the mailbox access key for that mailbox is
   used as the secret known to the IMAP server, and the same server-
   selected algorithm used for generating URLs is used to calculate the
   authorization token for verification.










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


7.  Additional Commands

   These commands are extensions to the [IMAP] base protocol.

   The section headings of these commands are intended to correspond
   with where they would be located in the base protocol document if
   they were part of that document.

BASE.6.3.RESETKEY.  RESETKEY Command

   Arguments:  optional mailbox name
               optional mechanism name(s)

   Responses:  none other than in result

   Result:     OK - RESETKEY completed, URLMECH containing new data
               NO - RESETKEY error: can't change key of that mailbox
               BAD - command unknown or arguments invalid

   The RESETKEY command has two forms.

   The first form accepts a mailbox name as an argument and generates a
   new mailbox access key for the given mailbox in the user's mailbox
   access key table, replacing any previous mailbox access key (and
   revoking any URLs that were authorized with a URLAUTH using that key)
   in that table.  By default, the mailbox access key is generated for
   the INTERNAL mechanism; other mechanisms can be specified with the
   optional mechanism argument.

   The second form, with no arguments, removes all mailbox access keys
   in the user's mailbox access key table, revoking all URLs currently
   authorized using URLAUTH by the user.

   Any current IMAP session logged in as the user that has the mailbox
   selected will receive an untagged OK response with the URLMECH status
   response code (see section BASE.7.1.URLMECH for more details about
   the URLMECH status response code).

   Example:

      C: a31 RESETKEY
      S: a31 OK All keys removed
      C: a32 RESETKEY INBOX
      S: a32 OK [URLMECH INTERNAL] mechs
      C: a33 RESETKEY INBOX XSAMPLE
      S: a33 OK [URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg==] done





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


BASE.6.3.GENURLAUTH.  GENURLAUTH Command

      Argument:   one or more URL/mechanism pairs

      Response:   untagged response: GENURLAUTH

      Result:     OK - GENURLAUTH completed
                  NO - GENURLAUTH error: can't generate a URLAUTH
                  BAD - command unknown or arguments invalid

   The GENURLAUTH command requests that the server generate a URLAUTH-
   authorized URL for each of the given URLs using the given URL
   authorization mechanism.

   The server MUST validate each supplied URL as follows:

      (1) The mailbox component of the URL MUST refer to an existing
          mailbox.

      (2) The server component of the URL MUST contain a valid userid
          that identifies the owner of the mailbox access key table that
          will be used to generate the URLAUTH-authorized URL.  As a
          consequence, the iserver rule of [IMAPURL] is modified so that
          iuserauth is mandatory.

             Note: the server component of the URL is generally the
             logged in userid and server.  If not, then the logged in
             userid and server MUST have owner-type access to the
             mailbox access key table owned by the userid and server
             indicated by the server component of the URL.

      (3) There is a valid access identifier that, in the case of
          "submit+" and "user+", will contain a valid userid.  This
          userid is not necessarily the same as the owner userid
          described in (2).

      (4) The server MAY also verify that the iuid and/or isection
          components (if present) are valid.

   If any of the above checks fail, the server MUST return a tagged BAD
   response with the following exception.  If an invalid userid is
   supplied as the mailbox access key owner and/or as part of the access
   identifier, the server MAY issue a tagged OK response with a
   generated mailbox key that always fails validation when used with a
   URLFETCH command.  This exception prevents an attacker from
   validating userids.





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


   If there is currently no mailbox access key for the given mailbox in
   the owner's mailbox access key table, one is automatically generated.
   That is, it is not necessary to use RESETKEY prior to first-time use
   of GENURLAUTH.

   If the command is successful, a GENURLAUTH response code is returned
   listing the requested URLs as URLAUTH-authorized URLs.

   Examples:

      C: a775 GENURLAUTH "imap://[e-mail]/INBOX/;uid=20/
         ;section=1.2" INTERNAL
      S: a775 BAD missing access identifier in supplied URL
      C: a776 GENURLAUTH "imap://example.com/Shared/;uid=20/
         ;section=1.2;urlauth=submit+fred" INTERNAL
      S: a776 BAD missing owner username in supplied URL
      C: a777 GENURLAUTH "imap://[e-mail]/INBOX/;uid=20/
         ;section=1.2;urlauth=submit+fred" INTERNAL
      S: * GENURLAUTH "imap://[e-mail]/INBOX/;uid=20/;section=1.2
         ;urlauth=submit+fred:internal:91354a473744909de610943775f92038"
      S: a777 OK GENURLAUTH completed

BASE.6.3.URLFETCH.  URLFETCH Command

      Argument:   one or more URLs

      Response:   untagged response: URLFETCH

      Result:     OK - urlfetch completed
                  NO - urlfetch failed due to server internal error
                  BAD - command unknown or arguments invalid

   The URLFETCH command requests that the server return the text data
   associated with the specified IMAP URLs, as described in [IMAPURL]
   and extended by this document.  The data is returned for all
   validated URLs, regardless of whether or not the session would
   otherwise be able to access the mailbox containing that data via
   SELECT or EXAMINE.

      Note: This command does not require that the URL refer to the
      selected mailbox; nor does it require that any mailbox be
      selected.  It also does not in any way interfere with any selected
      mailbox.








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


   The URLFETCH command effectively executes with the access of the
   userid in the server component of the URL (which is generally the
   userid that issued the GENURLAUTH).  By itself, the URLAUTH does NOT
   grant access to the data; once validated, it grants whatever access
   to the data is held by the userid in the server component of the URL.
   That access may have changed since the GENURLAUTH was done.

   The URLFETCH command MUST return an untagged URLFETCH response and a
   tagged OK response to any URLFETCH command that is syntactically
   valid.  A NO response indicates a server internal failure that may be
   resolved on later retry.

      Note: The possibility of a NO response is to accommodate
      implementations that would otherwise have to issue an untagged BYE
      with a fatal error due to an inability to respond to a valid
      request.  In an ideal world, a server SHOULD NOT issue a NO
      response.

   The server MUST return NIL for any IMAP URL that references an entire
   IMAP server, a list of mailboxes, an entire IMAP mailbox, or IMAP
   search results.

   Example:

      Note: For clarity, this example uses the LOGIN command, which
      SHOULD NOT be used over a non-encrypted communication path.

      This example is of a submit server, obtaining a message segment
      for a message that it has already validated was submitted by
      "fred".

      S: * OK [CAPABILITY IMAP4REV1 URLAUTH] example.com IMAP server
      C: a001 LOGIN submitserver secret
      S: a001 OK submitserver logged in
      C: a002 URLFETCH "imap://[e-mail]/INBOX/;uid=20/
         ;section=1.2;urlauth=submit+fred:internal
         :91354a473744909de610943775f92038"
      S: * URLFETCH "imap://[e-mail]/INBOX/;uid=20/;section=1.2
         ;urlauth=submit+fred:internal
         :91354a473744909de610943775f92038" {28}
      S: Si vis pacem, para bellum.
      S:
      S: a002 OK URLFETCH completed








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


8.  Additional Responses

   These responses are extensions to the [IMAP] base protocol.

   The section headings of these responses are intended to correspond
   with where they would be located in the base protocol document if
   they were part of that document.

BASE.7.1.URLMECH.  URLMECH Status Response Code

   The URLMECH status response code is followed by a list of URL
   authorization mechanism names.  Mechanism names other than INTERNAL
   may be appended with an "=" and BASE64-encoded form of mechanism-
   specific data.

   This status response code is returned in an untagged OK response in
   response to a RESETKEY, SELECT, or EXAMINE command.  In the case of
   the RESETKEY command, this status response code can be sent in the
   tagged OK response instead of requiring a separate untagged OK
   response.

   Example:

      C: a33 RESETKEY INBOX XSAMPLE
      S: a33 OK [URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg==] done

   In this example, the server supports the INTERNAL mechanism and an
   experimental mechanism called XSAMPLE, which also holds some
   mechanism-specific data (the name "XSAMPLE" is for illustrative
   purposes only).

BASE.7.4.GENURLAUTH.   GENURLAUTH Response

   Contents:   One or more URLs

   The GENURLAUTH response returns the URLAUTH-authorized URL(s)
   requested by a GENURLAUTH command.

   Example:

      C: a777 GENURLAUTH "imap://[e-mail]/INBOX/;uid=20/
         ;section=1.2;urlauth=submit+fred" INTERNAL
      S: * GENURLAUTH "imap://[e-mail]/INBOX/;uid=20/;section=1.2
         ;urlauth=submit+fred:internal:91354a473744909de610943775f92038"
      S: a777 OK GENURLAUTH completed






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