--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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://joe@example.com/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://joe@example.com/INBOX/;uid=20/
+ ;section=1.2;urlauth=submit+fred" INTERNAL
+ S: * GENURLAUTH "imap://joe@example.com/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]
+\f
+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://joe@example.com/INBOX/;uid=20/
+ ;section=1.2;urlauth=submit+fred:internal
+ :91354a473744909de610943775f92038"
+ S: * URLFETCH "imap://joe@example.com/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]
+\f
+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://joe@example.com/INBOX/;uid=20/
+ ;section=1.2;urlauth=submit+fred" INTERNAL
+ S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
+ ;urlauth=submit+fred:internal:91354a473744909de610943775f92038"
+ S: a777 OK GENURLAUTH completed
+
+
+
+
+
+
+Crispin Standards Track [Page 12]
+\f
+RFC 4467 IMAP - URLAUTH Extension May 2006
+
+
+BASE.7.4.URLFETCH. URLFETCH Response
+
+ Contents: One or more URL/nstring pairs
+
+ The URLFETCH response returns the message text data associated with
+ one or more IMAP URLs, as described in [IMAPURL] and extended by this
+ document. This response occurs as the result of a URLFETCH command.
+
+ The returned data string is NIL if the URL is invalid for any reason
+ (including validation failure). If the URL is valid, but the IMAP
+ fetch of the body part returned NIL (this should not happen), the
+ returned data string should be the empty string ("") and not NIL.
+
+ 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.
+
+ Example:
+
+ C: a002 URLFETCH "imap://joe@example.com/INBOX/;uid=20/
+ ;section=1.2;urlauth=submit+fred:internal
+ :91354a473744909de610943775f92038"
+ S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
+ ;urlauth=submit+fred:internal
+ :91354a473744909de610943775f92038" {28}
+ S: Si vis pacem, para bellum.
+ S:
+ S: a002 OK URLFETCH completed
+
+9. Formal Syntax
+
+ The following syntax specification uses the Augmented Backus-Naur
+ Form (ABNF) notation as specified in [ABNF].
+
+ The following modifications are made to the Formal Syntax in [IMAP]:
+
+resetkey = "RESETKEY" [SP mailbox *(SP mechanism)]
+
+capability =/ "URLAUTH"
+
+command-auth =/ resetkey / genurlauth / urlfetch
+
+resp-text-code =/ "URLMECH" SP "INTERNAL" *(SP mechanism ["=" base64])
+
+genurlauth = "GENURLAUTH" 1*(SP url-rump SP mechanism)
+
+genurlauth-data = "*" SP "GENURLAUTH" 1*(SP url-full)
+
+
+
+Crispin Standards Track [Page 13]
+\f
+RFC 4467 IMAP - URLAUTH Extension May 2006
+
+
+url-full = astring
+ ; contains authimapurlfull as defined below
+
+url-rump = astring
+ ; contains authimapurlrump as defined below
+
+urlfetch = "URLFETCH" 1*(SP url-full)
+
+urlfetch-data = "*" SP "URLFETCH" 1*(SP url-full SP nstring)
+
+ The following extensions are made to the Formal Syntax in [IMAPURL]:
+
+authimapurl = "imap://" enc-user [iauth] "@" hostport "/"
+ imessagepart
+ ; replaces "imapurl" and "iserver" rules for
+ ; URLAUTH authorized URLs
+
+authimapurlfull = authimapurl iurlauth
+
+authimapurlrump = authimapurl iurlauth-rump
+
+enc-urlauth = 32*HEXDIG
+
+enc-user = 1*achar
+ ; same as "enc_user" in RFC 2192
+
+iurlauth = iurlauth-rump ":" mechanism ":" enc-urlauth
+
+iurlauth-rump = [expire] ";URLAUTH=" access
+
+access = ("submit+" enc-user) / ("user+" enc-user) /
+ "authuser" / "anonymous"
+
+expire = ";EXPIRE=" date-time
+ ; date-time defined in [DATETIME]
+
+mechanism = "INTERNAL" / 1*(ALPHA / DIGIT / "-" / ".")
+ ; case-insensitive
+ ; new mechanisms MUST be registered with IANA
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin Standards Track [Page 14]
+\f
+RFC 4467 IMAP - URLAUTH Extension May 2006
+
+
+10. Security Considerations
+
+ Security considerations are discussed throughout this memo.
+
+ The mailbox access key SHOULD have at least 128 bits of entropy
+ (refer to [RANDOM] for more details) and MUST be unpredictable.
+
+ The server implementation of the INTERNAL mechanism SHOULD consider
+ the possibility of needing to change the token generation algorithm,
+ and SHOULD incorporate some means of identifying the token generation
+ algorithm within the token.
+
+ The URLMECH status response code may expose sensitive data in the
+ mechanism-specific data for mechanisms other than INTERNAL. A server
+ implementation MUST implement a configuration that will not return a
+ URLMECH status response code unless some mechanism is provided that
+ protects the session from snooping, such as a TLS or SASL security
+ layer that provides confidentiality protection.
+
+ The calculation of an authorization token with a "plausible" key if
+ the mailbox can not be identified is necessary to avoid attacks in
+ which the server is probed to see if a particular mailbox exists on
+ the server by measuring the amount of time taken to reject a known
+ bad name versus some other name.
+
+ To protect against a computational denial-of-service attack, a server
+ MAY impose progressively longer delays on multiple URL requests that
+ fail validation.
+
+ The decision to use the "authuser" access identifier should be made
+ with caution. An "authuser" access identifier can be used by any
+ authorized user of the IMAP server; therefore, use of this access
+ identifier should be limited to content that may be disclosed to any
+ authorized user of the IMAP server.
+
+ The decision to use the "anonymous" access identifier should be made
+ with extreme caution. An "anonymous" access identifier can be used
+ by anyone; therefore, use of this access identifier should be limited
+ to content that may be disclosed to anyone. Many IMAP servers do not
+ permit anonymous access; in this case, the "anonymous" access
+ identifier is equivalent to "authuser", but this MUST NOT be relied
+ upon.
+
+ Although this specification does not prohibit the theoretical
+ capability to generate a URL with a server component other than the
+ logged in userid and server, this capability should only be provided
+
+
+
+
+
+Crispin Standards Track [Page 15]
+\f
+RFC 4467 IMAP - URLAUTH Extension May 2006
+
+
+ when the logged in userid/server has been authorized as equivalent to
+ the server component userid/server, or otherwise has access to that
+ userid/server mailbox access key table.
+
+11. IANA Considerations
+
+ This document constitutes registration of the URLAUTH capability in
+ the imap4-capabilities registry.
+
+ URLAUTH authorization mechanisms are registered by publishing a
+ standards track or IESG-approved experimental RFC. The registry is
+ currently located at:
+
+http://www.iana.org/assignments/urlauth-authorization-mechanism-registry
+
+ This registry is case-insensitive.
+
+ This document constitutes registration of the INTERNAL URLAUTH
+ authorization mechanism.
+
+ IMAP URLAUTH Authorization Mechanism Registry
+
+ Mechanism Name Reference
+ -------------- ---------
+ INTERNAL [RFC4467]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin Standards Track [Page 16]
+\f
+RFC 4467 IMAP - URLAUTH Extension May 2006
+
+
+12. Normative References
+
+ [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [BURL] Newman, C., "Message Submission BURL Extension", RFC 4468,
+ May 2006.
+
+ [DATETIME] Klyne, G. and C. Newman, "Date and Time on the Internet:
+ Timestamps", RFC 3339, July 2002.
+
+ [IMAP] Crispin, M., "Internet Message Access Protocol - Version
+ 4rev1", RFC 3501, March 2003.
+
+ [IMAPURL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
+
+ [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+13. Informative References
+
+ [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+ Hashing for Message Authentication", RFC 2104, February
+ 1997.
+
+ [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+ "Randomness Requirements for Security", BCP 106, RFC 4086,
+ June 2005.
+
+Author's Address
+
+ Mark R. Crispin
+ Networks and Distributed Computing
+ University of Washington
+ 4545 15th Avenue NE
+ Seattle, WA 98105-4527
+
+ Phone: (206) 543-5762
+ EMail: MRC@CAC.Washington.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin Standards Track [Page 17]
+\f
+RFC 4467 IMAP - URLAUTH Extension May 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Crispin Standards Track [Page 18]
+\f
projects / uw-imap / commitdiff