idnits 2.17.1 draft-ietf-lemonade-urlauth-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 775. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 786. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 793. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 799. ** Found boilerplate matching RFC 3979, Section 5, paragraph 1 (on line 786), which is fine, but *also* found old RFC 2026, Section 10.4A text on line 752. ** Found boilerplate matching RFC 3979, Section 5, paragraph 3 (on line 799), which is fine, but *also* found old RFC 2026, Section 10.4B text on line 758. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 829 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 74 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3979, Section 5, paragraph 1 boilerplate, a section with a similar start was also found: The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. == In addition to RFC 3979, Section 5, paragraph 3 boilerplate, a section with a similar start was also found: The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2005) is 6767 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'URLMECH INTERNAL' is mentioned on line 378, but not defined -- Possible downref: Normative reference to a draft: ref. 'BURL' ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 2192 (ref. 'IMAPURL') (Obsoleted by RFC 5092) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 1750 (ref. 'RANDOM') (Obsoleted by RFC 4086) Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Crispin 3 INTERNET-DRAFT: IMAP URLAUTH University of Washington 4 October 2005 5 Document: internet-drafts/draft-ietf-lemonade-urlauth-08.txt 7 Internet Message Access Protocol (IMAP) - URLAUTH Extension 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that 12 any applicable patent or other IPR claims of which he or she is 13 aware have been or will be disclosed, and any of which he or she 14 becomes aware will be disclosed, in accordance with Section 6 of 15 BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 A revised version of this draft document will be submitted to the RFC 34 editor as a Proposed Standard for the Internet Community. Discussion 35 and suggestions for improvement are requested, and should be sent to 36 lemonade@IETF.ORG. This document will expire before 3 April 37 2006. Distribution of this memo is unlimited. 39 Abstract 41 This document describes the URLAUTH extension to the Internet 42 Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme 43 (IMAPURL) (RFC 2192). This extension provides a means by which an 44 IMAP client can use URLs carrying authorization to access limited 45 message data on the IMAP server. 47 An IMAP server which supports this extension indicates this with a 48 capability name of "URLAUTH". 50 Conventions Used in this Document 52 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 53 in this document are to be interpreted as defined in [KEYWORDS]. 55 The formal syntax uses the Augmented Backus-Naur Form (ABNF) 56 notation including the core rules defined in Appendix A of [ABNF]. 58 In examples, "C:" and "S:" indicate lines sent by the client and 59 server respectively. If a single "C:" or "S:" label applies to 60 multiple lines, then the line breaks between those lines are for 61 editorial clarity only and are not part of the actual protocol 62 exchange. 64 Introduction 66 In [IMAPURL], a URL of the form imap://fred@example.com/INBOX/;uid=20 67 requires authorization as userid "fred". However, [IMAPURL] implies 68 that it only supports authentication, and confuses the concepts 69 authentication and authorization. 71 The URLAUTH extension defines an authorization mechanism for IMAP 72 URLs to replace [IMAPURL]'s authentication-only mechanism. URLAUTH 73 conveys authorization in the URL name itself, and reuses a portion of 74 the syntax of the [IMAPURL] authentication mechanism to convey the 75 authorization identity (which also defines the default namespace in 76 [IMAP]). 78 The URLAUTH extension provides a means by which an authorized user of 79 an IMAP server can create URLAUTH authorized IMAP URLs. A URLAUTH 80 authorized URL conveys authorization (not authentication) to the data 81 addressed by that URL. This URL can be used in another IMAP session 82 to access specific content on the IMAP server, without otherwise 83 providing authorization to any other data (such as other data in the 84 mailbox specified in the URL) owned by the authorizing user. 86 Conceptually, a URLAUTH authorized URL can be thought of as a "pawn 87 ticket" which carries no authentication information and can be 88 redeemed by whomever presents it. However, unlike a pawn ticket, 89 URLAUTH has optional mechanisms to restrict the usage a URLAUTH 90 authorized URL. Using these mechanisms, URLAUTH authorized URLs can 91 be usable by: 92 . anonymous (the "pawn ticket" model) 93 . authenticated users only 94 . a specific authenticated user only 95 . message submission acting on behalf of a specific user only 96 There is also a mechanism for expiration. 98 A URLAUTH authorized URL can be used in the argument to the BURL 99 command in message composition, as described in [BURL], for such 100 purposes as a memory (or other resource) constrained client 101 submitting a message forward or resend from an IMAP mailbox without 102 requiring the client to fetch that message data. 104 The URLAUTH is generated using an authorization mechanism name and an 105 authorization token, which is generated using a secret mailbox access 106 key. An IMAP client can request the server to generate and assign a 107 new mailbox access key (thus effectively revoking all current URLs 108 using URLAUTH with the old mailbox access key) but can not set the 109 mailbox access key to a key of its own choosing. 111 1. Concepts 113 1.1. URLAUTH 115 The URLAUTH is a component, appended at the end of a URL, which 116 conveys authorization to access the data addressed by that URL. It 117 contains an authorized access identifier, an authorization 118 mechanism name, and an authorization token. The authorization 119 token is generated from the URL, the authorized access identifer, 120 authorization mechanism name, and a mailbox access key. 122 1.2. Mailbox Access Key 124 The mailbox access key is a random string with at least 128 bits of 125 entropy. It is generated by software (not by the human user), and 126 MUST be unpredictable. 128 Each user has a table of mailboxes and an associated mailbox access 129 key for each mailbox. Consequently, the mailbox access key is 130 per-user and per-mailbox. In other words, two users sharing the 131 same mailbox each have a different mailbox access key for that 132 mailbox, and each mailbox accessed by a single user also has a 133 different mailbox access key. 135 1.3. Authorized Access Identifier 137 The authorized access identifier restricts use of the URLAUTH 138 authorized URL to certain users authorized on the server, as 139 described in section 2. 141 1.4. Authorization Mechanism 143 The authorization mechanism is the algorithm by which the URLAUTH is 144 generated and subsequently verified, using the mailbox access key. 146 1.4.1 INTERNAL Authorization Mechanism 148 This specification defines the INTERNAL mechanism, which uses a token 149 generation algorithm of the server's choosing and does not involve 150 disclosure of the mailbox access key to the client. 152 Note: The token generation algorithm chosen by the server 153 implementation should be modern and reasonably secure. At the 154 time of the writing of this document, an [HMAC] such as HMAC-SHA1 155 is recommended. 157 If it becomes necesary to change the token generation algorithm of 158 the INTERNAL mechanism (e.g., because an attack against the 159 current algorithm has been discovered), all currently existing 160 URLAUTH authorized URLs are invalidated by the change in 161 algorithm. Since this would be an unpleasant surprise to 162 applications which depend upon the validity of a URLAUTH 163 authorized URL, and there is no good way to do a bulk update of 164 existing deployed URLs, it is best to avoid this situation by 165 using a secure algorithm as opposed to one that is "good enough". 167 Server implementations SHOULD consider the possibility of changing 168 the algorithm. In some cases, it may be desirable to implement 169 the change of algorithm in a way that newly-generated tokens use 170 the new algorithm, but for a limited period of time tokens using 171 either the new or old algorithm can be validated. Consequently, 172 the server SHOULD incorporate some means of identifying the token 173 generation algorithm within the token. 175 Although this specification is extensible for other mechanisms, none 176 are defined in this document. In addition to the mechanism name 177 itself, other mechanisms may have mechanism specific data, which is 178 to be interpreted according to the definition of that mechanism. 180 1.5. Authorization Token 182 The authorization token is a deterministic string of at least 128 183 bits which an entity with knowledge of the secret mailbox access key 184 and URL authorization mechanism can use to verify the URL. 186 2. IMAP URL Extensions 188 [IMAPURL] is extended by allowing the addition of ;EXPIRE=" 189 and ";URLAUTH=::" to IMAP URLs which refer to 190 a specific message or message parts. 192 The URLAUTH is comprised of ";URLAUTH=::", and 193 MUST be at the end of the URL. 195 URLAUTH does not apply to, and MUST NOT be used with, any IMAP URL 196 which refers to an entire IMAP server, list of mailboxes, an entire 197 IMAP mailbox, or IMAP search results. 199 When ";EXPIRE=" is used, this indicates the latest date and 200 time that the URL is valid. After that date and time, the URL has 201 expired and server implementations MUST reject the URL. If 202 ";EXPIRE=" is not used, the URL has no expiration, but 203 still can be revoked as discussed below. 205 The URLAUTH takes the form ";URLAUTH=::". It is 206 composed of three parts. The portion provides the 207 authorized access identifiers which may constrain the operations and 208 users that are permitted to use this URL. The portion 209 provides the authorization mechanism used by the IMAP server to 210 generate the authorization token that follows. The portion 211 provides authorization token. 213 The "submit+" access identifier prefix, followed by a userid, 214 indicates that only a userid authorized as a message submission 215 entity on behalf of the specified userid is permitted to use this 216 URL. The IMAP server does not validate the specified userid but does 217 validate that the IMAP session has an authorization identity that is 218 authorized as a message submission entity. The authorized message 219 submission entity MUST validate the userid prior to contacting the 220 IMAP server. 222 The "user+" access identifier prefix, followed by a userid, indicates 223 that use of this URL is limited to IMAP sessions which are logged in 224 as the specified userid (that is, have authorization identity as that 225 userid). 227 Note: if a SASL mechanism which provides both authorization and 228 authentication identifiers is used to authenticate to the IMAP 229 server, the "user+" access identifier MUST match the authorization 230 identifier. 232 The "authuser" access identifier indicates that use of this URL is 233 limited to IMAP sessions which are logged in as an authorized user 234 (that is, have authorization identity as an authorized user) of 235 that IMAP server. Use of this URL is prohibited to anonymous IMAP 236 sessions. 238 The "anonymous" access identifier indicates that use of this URL is 239 not restricted by session authorization identity; that is, any IMAP 240 session in authenticated or selected state (as defined in [IMAP]), 241 including anonymous sessions, may issue a URLFETCH using this URL. 243 The authorization token is represented as an ASCII-encoded 244 hexadecimal string, which is used to authorize the URL. The length 245 and the calculation of the authorization token depends upon the 246 mechanism used; but, in all cases, the authorization token is at 247 least 128 bits (and therefore at least 32 hexadecimal digits). 249 3. Discussion of URLAUTH Authorization Issues 251 In [IMAPURL], the userid before the "@" in the URL has two purposes: 252 1) It provides context for user-specific mailbox paths such 253 as "INBOX". 254 2) It specifies that resolution of the URL requires logging in as 255 that user and limits use of that URL to only that user. 256 An obvious limitation of using the same field for both purposes is 257 that the URL can only be resolved by the mailbox owner. 259 URLAUTH overrides the second purpose of the userid in the IMAP URL 260 and by default permits the URL to be resolved by any user permitted 261 by the access identifier. 263 The "user+" access identifier limits resolution of that URL 264 to a particular userid, whereas the "submit+" access 265 identifier is more general and simply requires that the session be 266 authorized by a user that has been granted a "submit" role within 267 the authentication system. Use of either of these access 268 identifiers makes it impossible for an attacker, spying on the 269 session, to use the same URL, either directly or by submission to a 270 message submission entity. 272 The "authuser" and "anonymous" access identifiers do not have this 273 level of protection, and should be used with caution. These access 274 identifiers are primarily useful for public export of data from an 275 IMAP server, without requiring that it be copied to a web or 276 anonymous FTP server. Refer to the Security Considerations for 277 more details. 279 4. Generation of URLAUTH authorized URLs 281 A URLAUTH authorized URL is generated from an initial URL as follows: 283 An initial URL is built, ending with ";URLAUTH=" but 284 without the "::" components. An authorization 285 mechanism is selected and used to calculate the authorization 286 token, with the initial URL as the data and a secret known to the 287 IMAP server as the key. The URLAUTH authorized URL is generated by 288 taking the initial URL and appending ":", the URL authorization 289 mechanism name, ":", and the ASCII-encoded hexadecimal 290 representation of the authorization token. 292 Note: ASCII-encoded hexadecimal is used instead of BASE64 293 because a BASE64 representation may have "=" padding characters 294 which would be problematic in a URL. 296 In the INTERNAL mechanism, the mailbox access key for that mailbox is 297 the secret known to the IMAP server, and a server-selected algorithm 298 is used as described in section 1.4.1. 300 5. Validation of URLAUTH authorized URLs 302 A URLAUTH authorized URL is validated as follows: 304 The URL is split at the ":" which separates "" from 305 ":" in the ";URLAUTH=::" portion 306 of the URL. The ":" portion is first parsed and saved 307 as the authorization mechanism and the authorization token. The 308 URL is truncated, discarding the ":" described above, to create a 309 "rump URL" (the URL minus the ":" and the ":" 310 portion). The rump URL is then analyzed to identify the mailbox. 312 If the mailbox cannot be identified, an authorization token is 313 calculated on the rump URL, using random "plausible" keys (selected 314 by the server) as needed, before returning a validation failure. 315 This prevents timing attacks aimed at identifying mailbox names. 317 If the mailbox can be identified, the authorization token is 318 calculated on the rump URL and a secret known to the IMAP server 319 using the given URL authorization mechanism. Validation is 320 successful if, and only if, the calculated authorization token for 321 that mechanism matches the authorization token supplied in 322 ";URLAUTH=::". 324 Removal of the "::" portion of the URL MUST be the 325 only operation applied to the URLAUTH authorized URL to get the 326 rump URL. In particular, URL percent escape decoding and 327 case-folding (including to the domain part of the URL) MUST NOT 328 occur. 330 In the INTERNAL mechanism, the mailbox access key for that mailbox 331 is used as the secret known to the IMAP server, and the same 332 server-selected algorithm used for generating URLs is used to 333 calculate the authorization token for verification. 335 6. Additional Commands 337 These commands are extension to the [IMAP] base protocol. 339 The section headings of these commands are intended to correspond 340 with where they would be located in the base protocol document if 341 they were part of that document. 343 BASE.6.3.RESETKEY. RESETKEY Command 345 Arguments: optional mailbox name 346 optional mechanism name(s) 348 Responses: none other than in result 350 Result: OK - RESETKEY completed, URLMECH containing new data 351 NO - RESETKEY error: can't change key of that mailbox 352 BAD - command unknown or arguments invalid 354 The RESETKEY command has two forms. 356 The first form accepts a mailbox name as an argument, and generates 357 a new mailbox access key for the given mailbox in the user's 358 mailbox access key table, replacing any previous mailbox access key 359 (and revoking any URLs that were authorized with a URLAUTH using 360 that key) in that table. By default, the mailbox access key is 361 generated for the INTERNAL mechanism; other mechanisms can be 362 specified with the optional mechanism argument. 364 The second form, with no arguments, removes all mailbox access keys 365 in the user's mailbox access key table, revoking all URLs currently 366 authorized using URLAUTH by the user. 368 Any current IMAP session logged in as the user which has the mailbox 369 selected will receive an untagged OK response with the URLMECH status 370 response code (see section BASE.7.1.URLMECH for more details about 371 the URLMECH status response code). 373 Example: 375 C: a31 RESETKEY 376 S: a31 OK All keys removed 377 C: a32 RESETKEY INBOX 378 S: a32 OK [URLMECH INTERNAL] mechs 379 C: a33 RESETKEY INBOX XSAMPLE 380 S: a33 OK [URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg==] done 382 BASE.6.3.GENURLAUTH. GENURLAUTH Command 384 Argument: one or more URL/mechanism pairs 386 Response: untagged response: GENURLAUTH 388 Result: OK - GENURLAUTH completed 389 NO - GENURLAUTH error: can't generate a URLAUTH 390 BAD - command unknown or arguments invalid 392 The GENURLAUTH command requests the server to generate a URLAUTH 393 authorized URL for each of the given URLs using the given URL 394 authorization mechanism. 396 The server MUST validate each supplied URL as follows: 398 (1) the mailbox component of the URL MUST refer to an existing 399 mailbox. 401 (2) the server component of the URL MUST contain a valid userid 402 that identifies the owner of the mailbox access key table 403 that will be used to generate the URLAUTH authorized URL. 404 As a consequence, the iserver rule of [IMAPURL] is modified 405 so that iuserauth is mandatory. 407 (3) there is a valid access identifier which, in the case of 408 "submit+" and "user+", will contain a valid userid. This 409 userid is not necessarily the same as the owner userid 410 described in (2). 412 (4) the server MAY also verify that the Message-ID and/or 413 second components (if present) are valid. 415 If any of the above checks fail, the server MUST return a tagged 416 BAD response with the following exception. In the case of an 417 invalid userid supplied as the mailbox access key owner and/or as 418 part of the access identifier, the server MAY issue a tagged OK 419 response with a generated mailbox key that always fails validation 420 when used with a URLFETCH command. This exception prevents an 421 attacker from validating userids. 423 If there is currently no mailbox access key for the given mailbox 424 in the owner's mailbox access key table, one is automatically 425 generated. That is, it is not necessary to use RESETKEY prior to 426 first-time use of GENURLAUTH. 428 If the command is successful, a GENURLAUTH response code is returned 429 listing the requested URLs as URLAUTH authorized URLs. 431 Examples: 433 C: a775 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/ 434 ;section=1.2" INTERNAL 435 S: a775 BAD missing access identifier in supplied URL 436 C: a776 GENURLAUTH "imap://example.com/Shared/;uid=20/ 437 ;section=1.2;urlauth=submit+fred" INTERNAL 438 S: a776 BAD missing owner username in supplied URL 439 C: a777 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/ 440 ;section=1.2;urlauth=submit+fred" INTERNAL 441 S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/;section=1.2 442 ;urlauth=submit+fred:internal:91354a473744909de610943775f92038" 443 S: a777 OK GENURLAUTH completed 445 BASE.6.3.URLFETCH. URLFETCH Command 447 Argument: one or more URLs 449 Response: untagged response: URLFETCH 451 Result: OK - urlfetch completed 452 NO - urlfetch failed due to server internal error 453 BAD - command unknown or arguments invalid 455 The URLFETCH command requests that the server return the text data 456 associated with the specified IMAP URLs, as described in [IMAPURL] 457 and extended by this document. The data is returned for all 458 validated URLs, regardless of whether or not the session would 459 otherwise be able to access the mailbox containing that data via 460 SELECT or EXAMINE. 462 Note: This command does not require that the URL refer to the 463 selected mailbox; nor does it require that any mailbox be 464 selected. It also does not in any way interfere with any selected 465 mailbox. 467 The URLFETCH command MUST return an untagged URLFETCH response and a 468 tagged OK response to any URLFETCH command that is syntactically 469 valid. A NO response indicates a server internal failure which may 470 be resolved on later retry. 472 Note: the possibility of a NO response is to accommodate 473 implementations which would otherwise have to issue an 474 untagged BYE with a fatal error due to an inability to 475 respond to a valid request. In an ideal world, a server 476 SHOULD NOT issue a NO response. 478 The server MUST return NIL for any IMAP URL which references an 479 entire IMAP server, list of mailboxes, an entire IMAP mailbox, or 480 IMAP search results. 482 Example 484 Note: for clarity, this example uses the LOGIN command which 485 SHOULD NOT be used over a non-encrypted communication path. 487 This example is of a submit server, obtaining a message segment 488 for a message that it has already validated was submitted by 489 "fred". 491 S: * OK [CAPABILITY IMAP4REV1 URLAUTH] example.com IMAP server 492 C: a001 LOGIN submitserver secret 493 S: a001 OK submitserver logged in 494 C: a002 URLFETCH "imap://joe@example.com/INBOX/;uid=20/ 495 ;section=1.2;urlauth=submit+fred:internal 496 :91354a473744909de610943775f92038" 497 S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;section=1.2 498 ;urlauth=submit+fred:internal 499 :91354a473744909de610943775f92038" {28} 500 S: Si vis pacem, para bellum. 501 S: 502 S: a002 OK URLFETCH completed 504 7. Additional Responses 506 These responses are extensions to the [IMAP] base protocol. 508 The section headings of these responses are intended to correspond 509 with where they would be located in the base protocol document if 510 they were part of that document. 512 BASE.7.1.URLMECH. URLMECH Status Response Code 514 The URLMECH status response code is followed by a list of URL 515 authorization mechanism names. Mechanism names other than INTERNAL 516 may be appended with an "=" and BASE64 encoded form of mechanism 517 specific data. 519 This status response code is returned in an untagged OK response in 520 response to a RESETKEY, SELECT, or EXAMINE command. In the case of 521 the RESETKEY command, this status response code can be sent in the 522 tagged OK response instead of requiring a separate untagged OK 523 response. 525 Example: 527 C: a33 RESETKEY INBOX XSAMPLE 528 S: a33 OK [URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg==] done 530 In this example, the server supports the INTERNAL mechanism and an 531 experimental mechanism called XSAMPLE which also holds some mechanism 532 specific data (the name "XSAMPLE" is for illustrative purposes only). 534 BASE.7.4.GENURLAUTH. GENURLAUTH Response 536 Contents: One or more URLs 538 The GENURLAUTH response returns the URLAUTH authorized URL(s) 539 requested by a GENURLAUTH command. 541 Example: 543 C: a777 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/ 544 ;section=1.2;urlauth=submit+fred" INTERNAL 545 S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/;section=1.2 546 ;urlauth=submit+fred:internal:91354a473744909de610943775f92038" 547 S: a777 OK GENURLAUTH completed 549 BASE.7.4.URLFETCH. URLFETCH Response 551 Contents: One or more URL/nstring pairs 553 The URLFETCH response returns the message text data associated with 554 an IMAP URLs, as described in [IMAPURL] and extended by this 555 document. This response occurs as the result of a URLFETCH 556 command. 558 The returned data string is NIL if the URL is invalid for any reason 559 (including validation failure). If the URL is valid, but the IMAP 560 fetch of the body part returned NIL (this should not happen), the 561 returned data string should be the empty string ("") and not NIL. 563 Note: This command does not require that the URL refer to the 564 selected mailbox; nor does it require that any mailbox be 565 selected. It also does not in any way interfere with any selected 566 mailbox. 568 Example: 570 C: a002 URLFETCH "imap://joe@example.com/INBOX/;uid=20/ 571 ;section=1.2;urlauth=submit+fred:internal 572 :91354a473744909de610943775f92038" 573 S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;section=1.2 574 ;urlauth=submit+fred:internal 575 :91354a473744909de610943775f92038" {28} 576 S: Si vis pacem, para bellum. 577 S: 578 S: a002 OK URLFETCH completed 580 8. Formal Syntax 582 The following syntax specification uses the Augmented Backus-Naur 583 Form (ABNF) notation as specified in [ABNF]. 585 The following modifications are made to the Formal Syntax in [IMAP]: 587 resetkey = "RESETKEY" [SP mailbox *(SP mechanism)] 589 capability =/ "URLAUTH" 591 command-auth =/ resetkey / genurlauth / urlfetch 593 resp-text-code =/ "URLMECH" SP "INTERNAL" *(SP mechanism ["=" base64]) 595 genurlauth = "GENURLAUTH" 1*(SP url-rump SP mechanism) 597 genurlauth-data = "*" SP "GENURLAUTH" 1*(SP url-full) 599 url-full = astring 600 ; contains authimapurlfull as defined below 602 url-rump = astring 603 ; contains authimapurlrump as defined below 605 urlfetch = "URLFETCH" 1*(SP url-full) 607 urlfetch-data = "*" SP "URLFETCH" 1*(SP url-full SP nstring) 609 The following extensions are made to the Formal Syntax in [IMAPURL]: 611 authimapurl = "imap://" iuserauth "@" hostport "/" imessagepart 613 authimapurlfull = authimapurl iurlauth 615 authimapurlrump = authimapurl iurlauth-rump 617 enc-urlauth = 32*HEXDIG 619 iurlauth = iurlauth-rump ":" mechanism ":" enc-urlauth 621 iurlauth-rump = [expire] ";URLAUTH=" access 623 access = ("submit+" iuserauth) / ("user+" iuserauth) / 624 "authuser" / "anonymous" 626 expire = ";EXPIRE=" date-time 627 ; date-time defined in [DATETIME] 629 mechanism = "INTERNAL" / 1*(alpha / digit / "-" / ".") 630 ; case-insensitive 631 ; new mechanisms MUST be registered with IANA 633 9. Security Considerations 635 Security considerations are discussed throughout this memo. 637 The mailbox access key SHOULD have at least 128 bits of entropy 638 (refer to [RANDOM] for more details) and MUST be unpredictable. 640 The server implementation of the INTERNAL mechanism SHOULD consider 641 the possibility of needing to change the token generation algorithm, 642 and SHOULD incorporate some means of identifying the token generation 643 algorithm within the token. 645 The URLMECH status response code may expose sensitive data in the 646 mechanism specific data for mechanisms other than INTERNAL. A server 647 implementation MUST implement a configuration that will not return 648 a URLMECH status response code unless some mechanism is provided 649 that protects the session from snooping, such as a TLS or SASL 650 security layer that provides confidentiality protection. 652 The calculation of a authorization token with a "plausible" key if 653 the mailbox can not be identified is necessary to avoid attacks in 654 which the server is probed to see if a particular mailbox exists on 655 the server by measuring the amount of time taken to reject a known 656 bad name vs. some other name. 658 To protect against a computational denial-of-service attack, a server 659 MAY impose progressively longer delays on multiple URL requests that 660 fail validation. 662 The decision to use the "authuser" access identifier should be made 663 with caution. An "authuser" access identifier can be used by any 664 authorized user of the IMAP server; and therefore use of this access 665 identifier should be limited to content which may be disclosed to any 666 authorized user of the IMAP server. 668 The decision to use the "anonymous" access identifier should be 669 made with extreme caution. An "anonymous" access identifier can be 670 used by anyone; and therefore use of this access identifier should 671 be limited to content which may be disclosed to anyone. Many 672 IMAP servers do not permit anonymous access; in the case of such 673 servers the "anonymous" access identifer is equivalent to 674 "authuser", but this MUST NOT be relied upon. 676 IANA Considerations 678 This document consitutes registration of the URLAUTH capability in 679 the imap4-capabilities registry. 681 URLAUTH authorization mechanisms are registered by publishing a 682 standards track or IESG approved experimental RFC. The registry is 683 currently located at: 685 [to be defined by IANA] 687 This registry is case-insensitive. 689 This document consitutes registration of the INTERNAL URLAUTH 690 authorization mechanism. 692 IMAP URLAUTH Authorization Mechanism Registry 694 Mechanism Name Reference 695 -------------- --------- 696 INTERNAL [this document, to be filled in by IANA] 698 Normative References 700 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 701 Specifications: ABNF", draft-crocker-abnf-rfc2234bis (work 702 in progress). 704 [BURL] Newman, C., "Message Submission BURL Extension", 705 draft-newman-lemonade-burl (work in progress). 707 [DATETIME] Klyne, G., and Newman, C., "Date and Time on the Internet: 708 Timestamps", RFC 3339, July 2002. 710 [IMAP] Crispin, M., "Internet Message Access Protocol - Version 711 4rev1", RFC 3501, March 2003. 713 [IMAPURL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997. 715 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 716 Requirement Levels", BCP 14, RFC 2119, March 1997. 718 Informative References: 720 [HMAC] Krawczyk, H., Bellare, M., and Canetti, R., "HMAC: 721 Keyed-Hashing for Message Authentication", RFC 2104, 722 February 1997. 724 [RANDOM] Eastlake, D., Crocker, S., and Schiller, J., "Randomness 725 Recommendations for Security", RFC 1750, December 1994. 727 Author's Address 729 Mark R. Crispin 730 Networks and Distributed Computing 731 University of Washington 732 4545 15th Avenue NE 733 Seattle, WA 98105-4527 735 Phone: (206) 543-5762 736 EMail: MRC@CAC.Washington.EDU 738 Intellectual Property Statement 740 The IETF takes no position regarding the validity or scope of any 741 intellectual property or other rights that might be claimed to 742 pertain to the implementation or use of the technology described in 743 this document or the extent to which any license under such rights 744 might or might not be available; neither does it represent that it 745 has made any effort to identify any such rights. Information on the 746 IETF's procedures with respect to rights in standards-track and 747 standards-related documentation can be found in BCP-11. Copies of 748 claims of rights made available for publication and any assurances of 749 licenses to be made available, or the result of an attempt made to 750 obtain a general license or permission for the use of such 751 proprietary rights by implementors or users of this specification can 752 be obtained from the IETF Secretariat. 754 The IETF invites any interested party to bring to its attention any 755 copyrights, patents or patent applications, or other proprietary 756 rights which may cover technology that may be required to practice 757 this standard. Please address the information to the IETF Executive 758 Director. 760 Full Copyright Statement 762 Copyright (C) The Internet Society (2005). 764 This document is subject to the rights, licenses and restrictions 765 contained in BCP 78, and except as set forth therein, the authors 766 retain all their rights. 768 This document and the information contained herein are provided 769 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 770 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 771 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 772 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 773 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 774 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 775 PARTICULAR PURPOSE. 777 Intellectual Property 779 The IETF takes no position regarding the validity or scope of any 780 Intellectual Property Rights or other rights that might be claimed to 781 pertain to the implementation or use of the technology described in 782 this document or the extent to which any license under such rights 783 might or might not be available; nor does it represent that it has 784 made any independent effort to identify any such rights. Information 785 on the procedures with respect to rights in RFC documents can be 786 found in BCP 78 and BCP 79. 788 Copies of IPR disclosures made to the IETF Secretariat and any 789 assurances of licenses to be made available, or the result of an 790 attempt made to obtain a general license or permission for the use of 791 such proprietary rights by implementers or users of this 792 specification can be obtained from the IETF on-line IPR repository at 793 http://www.ietf.org/ipr. 795 The IETF invites any interested party to bring to its attention any 796 copyrights, patents or patent applications, or other proprietary 797 rights that may cover technology that may be required to implement 798 this standard. Please address the information to the IETF at ietf- 799 ipr@ietf.org. 801 Acknowledgement 803 Funding for the RFC Editor function is currently provided by the 804 Internet Society.