diff options
Diffstat (limited to 'imap/docs/rfc/rfc4467.txt')
| -rw-r--r-- | imap/docs/rfc/rfc4467.txt | 1011 |
1 files changed, 0 insertions, 1011 deletions
diff --git a/imap/docs/rfc/rfc4467.txt b/imap/docs/rfc/rfc4467.txt deleted file mode 100644 index 83b6516a..00000000 --- a/imap/docs/rfc/rfc4467.txt +++ /dev/null @@ -1,1011 +0,0 @@ - - - - - - -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 - - 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] - -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://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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - |