imapext-2007
view docs/rfc/rfc4467.txt @ 0:ada5e610ab86
imap-2007e
| author | yuuji@gentei.org |
|---|---|
| date | Mon, 14 Sep 2009 15:17:45 +0900 |
| parents | |
| children |
line source
7 Network Working Group M. Crispin
8 Request for Comments: 4467 University of Washington
9 Updates: 3501 May 2006
10 Category: Standards Track
13 Internet Message Access Protocol (IMAP) - URLAUTH Extension
15 Status of This Memo
17 This document specifies an Internet standards track protocol for the
18 Internet community, and requests discussion and suggestions for
19 improvements. Please refer to the current edition of the "Internet
20 Official Protocol Standards" (STD 1) for the standardization state
21 and status of this protocol. Distribution of this memo is unlimited.
23 Copyright Notice
25 Copyright (C) The Internet Society (2006).
27 Abstract
29 This document describes the URLAUTH extension to the Internet Message
30 Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL)
31 (RFC 2192). This extension provides a means by which an IMAP client
32 can use URLs carrying authorization to access limited message data on
33 the IMAP server.
35 An IMAP server that supports this extension indicates this with a
36 capability name of "URLAUTH".
38 1. Introduction
40 In [IMAPURL], a URL of the form imap://fred@example.com/INBOX/;uid=20
41 requires authorization as userid "fred". However, [IMAPURL] implies
42 that it only supports authentication and confuses the concepts of
43 authentication and authorization.
45 The URLAUTH extension defines an authorization mechanism for IMAP
46 URLs to replace [IMAPURL]'s authentication-only mechanism. URLAUTH
47 conveys authorization in the URL string itself and reuses a portion
48 of the syntax of the [IMAPURL] authentication mechanism to convey the
49 authorization identity (which also defines the default namespace in
50 [IMAP]).
52 The URLAUTH extension provides a means by which an authorized user of
53 an IMAP server can create URLAUTH-authorized IMAP URLs. A URLAUTH-
54 authorized URL conveys authorization (not authentication) to the data
58 Crispin Standards Track [Page 1]
60 RFC 4467 IMAP - URLAUTH Extension May 2006
63 addressed by that URL. This URL can be used in another IMAP session
64 to access specific content on the IMAP server, without otherwise
65 providing authorization to any other data (such as other data in the
66 mailbox specified in the URL) owned by the authorizing user.
68 Conceptually, a URLAUTH-authorized URL can be thought of as a "pawn
69 ticket" that carries no authentication information and can be
70 redeemed by whomever presents it. However, unlike a pawn ticket,
71 URLAUTH has optional mechanisms to restrict the usage of a URLAUTH-
72 authorized URL. Using these mechanisms, URLAUTH-authorized URLs can
73 be usable by:
75 . anonymous (the "pawn ticket" model)
76 . authenticated users only
77 . a specific authenticated user only
78 . message submission acting on behalf of a specific user only
80 There is also a mechanism for expiration.
82 A URLAUTH-authorized URL can be used in the argument to the BURL
83 command in message composition, as described in [BURL], for such
84 purposes as allowing a client (with limited memory or other
85 resources) to submit a message forward or to resend from an IMAP
86 mailbox without requiring the client to fetch that message data.
88 The URLAUTH is generated using an authorization mechanism name and an
89 authorization token, which is generated using a secret mailbox access
90 key. An IMAP client can request that the server generate and assign
91 a new mailbox access key (thus effectively revoking all current URLs
92 using URLAUTH with the old mailbox access key) but cannot set the
93 mailbox access key to a key of its own choosing.
95 1.1. Conventions Used in this Document
97 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
98 in this document are to be interpreted as defined in [KEYWORDS].
100 The formal syntax uses the Augmented Backus-Naur Form (ABNF) notation
101 including the core rules defined in Appendix A of [ABNF].
103 In examples, "C:" and "S:" indicate lines sent by the client and
104 server, respectively. If a single "C:" or "S:" label applies to
105 multiple lines, then the line breaks between those lines are for
106 editorial clarity only and are not part of the actual protocol
107 exchange.
114 Crispin Standards Track [Page 2]
116 RFC 4467 IMAP - URLAUTH Extension May 2006
119 2. Concepts
121 2.1. URLAUTH
123 The URLAUTH is a component, appended at the end of a URL, that
124 conveys authorization to access the data addressed by that URL. It
125 contains an authorized access identifier, an authorization mechanism
126 name, and an authorization token. The authorization token is
127 generated from the URL, the authorized access identifier, the
128 authorization mechanism name, and a mailbox access key.
130 2.2. Mailbox Access Key
132 The mailbox access key is a random string with at least 128 bits of
133 entropy. It is generated by software (not by the human user) and
134 MUST be unpredictable.
136 Each user has a table of mailboxes and an associated mailbox access
137 key for each mailbox. Consequently, the mailbox access key is per-
138 user and per-mailbox. In other words, two users sharing the same
139 mailbox each have a different mailbox access key for that mailbox,
140 and each mailbox accessed by a single user also has a different
141 mailbox access key.
143 2.3. Authorized Access Identifier
145 The authorized access identifier restricts use of the URLAUTH
146 authorized URL to certain users authorized on the server, as
147 described in section 3.
149 2.4. Authorization Mechanism
151 The authorization mechanism is the algorithm by which the URLAUTH is
152 generated and subsequently verified, using the mailbox access key.
154 2.4.1. INTERNAL Authorization Mechanism
156 This specification defines the INTERNAL mechanism, which uses a token
157 generation algorithm of the server's choosing and does not involve
158 disclosure of the mailbox access key to the client.
160 Note: The token generation algorithm chosen by the server
161 implementation should be modern and reasonably secure. At the
162 time of the writing of this document, an [HMAC] such as HMAC-SHA1
163 is recommended.
170 Crispin Standards Track [Page 3]
172 RFC 4467 IMAP - URLAUTH Extension May 2006
175 If it becomes necessary to change the token generation algorithm
176 of the INTERNAL mechanism (e.g., because an attack against the
177 current algorithm has been discovered), all currently existing
178 URLAUTH-authorized URLs are invalidated by the change in
179 algorithm. Since this would be an unpleasant surprise to
180 applications that depend upon the validity of a URLAUTH-authorized
181 URL, and there is no good way to do a bulk update of existing
182 deployed URLs, it is best to avoid this situation by using a
183 secure algorithm as opposed to one that is "good enough".
185 Server implementations SHOULD consider the possibility of changing
186 the algorithm. In some cases, it may be desirable to implement
187 the change of algorithm in a way that newly-generated tokens use
188 the new algorithm, but that for a limited period of time tokens
189 using either the new or old algorithm can be validated.
190 Consequently, the server SHOULD incorporate some means of
191 identifying the token generation algorithm within the token.
193 Although this specification is extensible for other mechanisms, none
194 are defined in this document. In addition to the mechanism name
195 itself, other mechanisms may have mechanism-specific data, which is
196 to be interpreted according to the definition of that mechanism.
198 2.5. Authorization Token
200 The authorization token is a deterministic string of at least 128
201 bits that an entity with knowledge of the secret mailbox access key
202 and URL authorization mechanism can use to verify the URL.
204 3. IMAP URL Extensions
206 [IMAPURL] is extended by allowing the addition of
207 ";EXPIRE=<datetime>" and ";URLAUTH=<access>:<mech>:<token>" to IMAP
208 URLs that refer to a specific message or message parts.
210 The URLAUTH is comprised of ";URLAUTH=<access>:<mech>:<token>" and
211 MUST be at the end of the URL.
213 URLAUTH does not apply to, and MUST NOT be used with, any IMAP URL
214 that refers to an entire IMAP server, a list of mailboxes, an entire
215 IMAP mailbox, or IMAP search results.
217 When ";EXPIRE=<datetime>" is used, this indicates the latest date and
218 time that the URL is valid. After that date and time, the URL has
219 expired, and server implementations MUST reject the URL. If
220 ";EXPIRE=<datetime>" is not used, the URL has no expiration, but
221 still can be revoked as discussed below.
226 Crispin Standards Track [Page 4]
228 RFC 4467 IMAP - URLAUTH Extension May 2006
231 The URLAUTH takes the form ";URLAUTH=<access>:<mech>:<token>". It is
232 composed of three parts. The <access> portion provides the
233 authorized access identifiers, which may constrain the operations and
234 users that are permitted to use this URL. The <mech> portion
235 provides the authorization mechanism used by the IMAP server to
236 generate the authorization token that follows. The <token> portion
237 provides the authorization token.
239 The "submit+" access identifier prefix, followed by a userid,
240 indicates that only a userid authorized as a message submission
241 entity on behalf of the specified userid is permitted to use this
242 URL. The IMAP server does not validate the specified userid but does
243 validate that the IMAP session has an authorization identity that is
244 authorized as a message submission entity. The authorized message
245 submission entity MUST validate the userid prior to contacting the
246 IMAP server.
248 The "user+" access identifier prefix, followed by a userid, indicates
249 that use of this URL is limited to IMAP sessions that are logged in
250 as the specified userid (that is, have authorization identity as that
251 userid).
253 Note: If a SASL mechanism that provides both authorization and
254 authentication identifiers is used to authenticate to the IMAP
255 server, the "user+" access identifier MUST match the authorization
256 identifier.
258 The "authuser" access identifier indicates that use of this URL is
259 limited to IMAP sessions that are logged in as an authorized user
260 (that is, have authorization identity as an authorized user) of that
261 IMAP server. Use of this URL is prohibited to anonymous IMAP
262 sessions.
264 The "anonymous" access identifier indicates that use of this URL is
265 not restricted by session authorization identity; that is, any IMAP
266 session in authenticated or selected state (as defined in [IMAP]),
267 including anonymous sessions, may issue a URLFETCH using this URL.
269 The authorization token is represented as an ASCII-encoded
270 hexadecimal string, which is used to authorize the URL. The length
271 and the calculation of the authorization token depends upon the
272 mechanism used; but, in all cases, the authorization token is at
273 least 128 bits (and therefore at least 32 hexadecimal digits).
282 Crispin Standards Track [Page 5]
284 RFC 4467 IMAP - URLAUTH Extension May 2006
287 4. Discussion of URLAUTH Authorization Issues
289 In [IMAPURL], the userid before the "@" in the URL has two purposes:
291 1) It provides context for user-specific mailbox paths such as
292 "INBOX".
294 2) It specifies that resolution of the URL requires logging in as
295 that user and limits use of that URL to only that user.
297 An obvious limitation of using the same field for both purposes is
298 that the URL can only be resolved by the mailbox owner.
300 URLAUTH overrides the second purpose of the userid in the IMAP URL
301 and by default permits the URL to be resolved by any user permitted
302 by the access identifier.
304 The "user+<userid>" access identifier limits resolution of that URL
305 to a particular userid, whereas the "submit+<userid>" access
306 identifier is more general and simply requires that the session be
307 authorized by a user that has been granted a "submit" role within the
308 authentication system. Use of either of these access identifiers
309 makes it impossible for an attacker, spying on the session, to use
310 the same URL, either directly or by submission to a message
311 submission entity.
313 The "authuser" and "anonymous" access identifiers do not have this
314 level of protection and should be used with caution. These access
315 identifiers are primarily useful for public export of data from an
316 IMAP server, without requiring that it be copied to a web or
317 anonymous FTP server. Refer to the Security Considerations for more
318 details.
320 5. Generation of URLAUTH-Authorized URLs
322 A URLAUTH-authorized URL is generated from an initial URL as follows:
324 An initial URL is built, ending with ";URLAUTH=<access>" but without
325 the ":<mech>:<token>" components. An authorization mechanism is
326 selected and used to calculate the authorization token, with the
327 initial URL as the data and a secret known to the IMAP server as the
328 key. The URLAUTH-authorized URL is generated by taking the initial
329 URL and appending ":", the URL authorization mechanism name, ":", and
330 the ASCII-encoded hexadecimal representation of the authorization
331 token.
338 Crispin Standards Track [Page 6]
340 RFC 4467 IMAP - URLAUTH Extension May 2006
343 Note: ASCII-encoded hexadecimal is used instead of BASE64 because
344 a BASE64 representation may have "=" padding characters, which
345 would be problematic in a URL.
347 In the INTERNAL mechanism, the mailbox access key for that mailbox is
348 the secret known to the IMAP server, and a server-selected algorithm
349 is used as described in section 2.4.1.
351 6. Validation of URLAUTH-authorized URLs
353 A URLAUTH-authorized URL is validated as follows:
355 The URL is split at the ":" that separates "<access>" from
356 "<mech>:<token>" in the ";URLAUTH=<access>:<mech>:<token>" portion of
357 the URL. The "<mech>:<token>" portion is first parsed and saved as
358 the authorization mechanism and the authorization token. The URL is
359 truncated, discarding the ":" described above, to create a "rump URL"
360 (the URL minus the ":" and the "<mech>:<token>" portion). The rump
361 URL is then analyzed to identify the mailbox.
363 If the mailbox cannot be identified, an authorization token is
364 calculated on the rump URL, using random "plausible" keys (selected
365 by the server) as needed, before returning a validation failure.
366 This prevents timing attacks aimed at identifying mailbox names.
368 If the mailbox can be identified, the authorization token is
369 calculated on the rump URL and a secret known to the IMAP server
370 using the given URL authorization mechanism. Validation is
371 successful if, and only if, the calculated authorization token for
372 that mechanism matches the authorization token supplied in
373 ";URLAUTH=<access>:<mech>:<token>".
375 Removal of the ":<mech>:<token>" portion of the URL MUST be the only
376 operation applied to the URLAUTH-authorized URL to get the rump URL.
377 In particular, URL percent escape decoding and case-folding
378 (including to the domain part of the URL) MUST NOT occur.
380 In the INTERNAL mechanism, the mailbox access key for that mailbox is
381 used as the secret known to the IMAP server, and the same server-
382 selected algorithm used for generating URLs is used to calculate the
383 authorization token for verification.
394 Crispin Standards Track [Page 7]
396 RFC 4467 IMAP - URLAUTH Extension May 2006
399 7. Additional Commands
401 These commands are extensions to the [IMAP] base protocol.
403 The section headings of these commands are intended to correspond
404 with where they would be located in the base protocol document if
405 they were part of that document.
407 BASE.6.3.RESETKEY. RESETKEY Command
409 Arguments: optional mailbox name
410 optional mechanism name(s)
412 Responses: none other than in result
414 Result: OK - RESETKEY completed, URLMECH containing new data
415 NO - RESETKEY error: can't change key of that mailbox
416 BAD - command unknown or arguments invalid
418 The RESETKEY command has two forms.
420 The first form accepts a mailbox name as an argument and generates a
421 new mailbox access key for the given mailbox in the user's mailbox
422 access key table, replacing any previous mailbox access key (and
423 revoking any URLs that were authorized with a URLAUTH using that key)
424 in that table. By default, the mailbox access key is generated for
425 the INTERNAL mechanism; other mechanisms can be specified with the
426 optional mechanism argument.
428 The second form, with no arguments, removes all mailbox access keys
429 in the user's mailbox access key table, revoking all URLs currently
430 authorized using URLAUTH by the user.
432 Any current IMAP session logged in as the user that has the mailbox
433 selected will receive an untagged OK response with the URLMECH status
434 response code (see section BASE.7.1.URLMECH for more details about
435 the URLMECH status response code).
437 Example:
439 C: a31 RESETKEY
440 S: a31 OK All keys removed
441 C: a32 RESETKEY INBOX
442 S: a32 OK [URLMECH INTERNAL] mechs
443 C: a33 RESETKEY INBOX XSAMPLE
444 S: a33 OK [URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg==] done
450 Crispin Standards Track [Page 8]
452 RFC 4467 IMAP - URLAUTH Extension May 2006
455 BASE.6.3.GENURLAUTH. GENURLAUTH Command
457 Argument: one or more URL/mechanism pairs
459 Response: untagged response: GENURLAUTH
461 Result: OK - GENURLAUTH completed
462 NO - GENURLAUTH error: can't generate a URLAUTH
463 BAD - command unknown or arguments invalid
465 The GENURLAUTH command requests that the server generate a URLAUTH-
466 authorized URL for each of the given URLs using the given URL
467 authorization mechanism.
469 The server MUST validate each supplied URL as follows:
471 (1) The mailbox component of the URL MUST refer to an existing
472 mailbox.
474 (2) The server component of the URL MUST contain a valid userid
475 that identifies the owner of the mailbox access key table that
476 will be used to generate the URLAUTH-authorized URL. As a
477 consequence, the iserver rule of [IMAPURL] is modified so that
478 iuserauth is mandatory.
480 Note: the server component of the URL is generally the
481 logged in userid and server. If not, then the logged in
482 userid and server MUST have owner-type access to the
483 mailbox access key table owned by the userid and server
484 indicated by the server component of the URL.
486 (3) There is a valid access identifier that, in the case of
487 "submit+" and "user+", will contain a valid userid. This
488 userid is not necessarily the same as the owner userid
489 described in (2).
491 (4) The server MAY also verify that the iuid and/or isection
492 components (if present) are valid.
494 If any of the above checks fail, the server MUST return a tagged BAD
495 response with the following exception. If an invalid userid is
496 supplied as the mailbox access key owner and/or as part of the access
497 identifier, the server MAY issue a tagged OK response with a
498 generated mailbox key that always fails validation when used with a
499 URLFETCH command. This exception prevents an attacker from
500 validating userids.
506 Crispin Standards Track [Page 9]
508 RFC 4467 IMAP - URLAUTH Extension May 2006
511 If there is currently no mailbox access key for the given mailbox in
512 the owner's mailbox access key table, one is automatically generated.
513 That is, it is not necessary to use RESETKEY prior to first-time use
514 of GENURLAUTH.
516 If the command is successful, a GENURLAUTH response code is returned
517 listing the requested URLs as URLAUTH-authorized URLs.
519 Examples:
521 C: a775 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/
522 ;section=1.2" INTERNAL
523 S: a775 BAD missing access identifier in supplied URL
524 C: a776 GENURLAUTH "imap://example.com/Shared/;uid=20/
525 ;section=1.2;urlauth=submit+fred" INTERNAL
526 S: a776 BAD missing owner username in supplied URL
527 C: a777 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/
528 ;section=1.2;urlauth=submit+fred" INTERNAL
529 S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
530 ;urlauth=submit+fred:internal:91354a473744909de610943775f92038"
531 S: a777 OK GENURLAUTH completed
533 BASE.6.3.URLFETCH. URLFETCH Command
535 Argument: one or more URLs
537 Response: untagged response: URLFETCH
539 Result: OK - urlfetch completed
540 NO - urlfetch failed due to server internal error
541 BAD - command unknown or arguments invalid
543 The URLFETCH command requests that the server return the text data
544 associated with the specified IMAP URLs, as described in [IMAPURL]
545 and extended by this document. The data is returned for all
546 validated URLs, regardless of whether or not the session would
547 otherwise be able to access the mailbox containing that data via
548 SELECT or EXAMINE.
550 Note: This command does not require that the URL refer to the
551 selected mailbox; nor does it require that any mailbox be
552 selected. It also does not in any way interfere with any selected
553 mailbox.
562 Crispin Standards Track [Page 10]
564 RFC 4467 IMAP - URLAUTH Extension May 2006
567 The URLFETCH command effectively executes with the access of the
568 userid in the server component of the URL (which is generally the
569 userid that issued the GENURLAUTH). By itself, the URLAUTH does NOT
570 grant access to the data; once validated, it grants whatever access
571 to the data is held by the userid in the server component of the URL.
572 That access may have changed since the GENURLAUTH was done.
574 The URLFETCH command MUST return an untagged URLFETCH response and a
575 tagged OK response to any URLFETCH command that is syntactically
576 valid. A NO response indicates a server internal failure that may be
577 resolved on later retry.
579 Note: The possibility of a NO response is to accommodate
580 implementations that would otherwise have to issue an untagged BYE
581 with a fatal error due to an inability to respond to a valid
582 request. In an ideal world, a server SHOULD NOT issue a NO
583 response.
585 The server MUST return NIL for any IMAP URL that references an entire
586 IMAP server, a list of mailboxes, an entire IMAP mailbox, or IMAP
587 search results.
589 Example:
591 Note: For clarity, this example uses the LOGIN command, which
592 SHOULD NOT be used over a non-encrypted communication path.
594 This example is of a submit server, obtaining a message segment
595 for a message that it has already validated was submitted by
596 "fred".
598 S: * OK [CAPABILITY IMAP4REV1 URLAUTH] example.com IMAP server
599 C: a001 LOGIN submitserver secret
600 S: a001 OK submitserver logged in
601 C: a002 URLFETCH "imap://joe@example.com/INBOX/;uid=20/
602 ;section=1.2;urlauth=submit+fred:internal
603 :91354a473744909de610943775f92038"
604 S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
605 ;urlauth=submit+fred:internal
606 :91354a473744909de610943775f92038" {28}
607 S: Si vis pacem, para bellum.
608 S:
609 S: a002 OK URLFETCH completed
618 Crispin Standards Track [Page 11]
620 RFC 4467 IMAP - URLAUTH Extension May 2006
623 8. Additional Responses
625 These responses are extensions to the [IMAP] base protocol.
627 The section headings of these responses are intended to correspond
628 with where they would be located in the base protocol document if
629 they were part of that document.
631 BASE.7.1.URLMECH. URLMECH Status Response Code
633 The URLMECH status response code is followed by a list of URL
634 authorization mechanism names. Mechanism names other than INTERNAL
635 may be appended with an "=" and BASE64-encoded form of mechanism-
636 specific data.
638 This status response code is returned in an untagged OK response in
639 response to a RESETKEY, SELECT, or EXAMINE command. In the case of
640 the RESETKEY command, this status response code can be sent in the
641 tagged OK response instead of requiring a separate untagged OK
642 response.
644 Example:
646 C: a33 RESETKEY INBOX XSAMPLE
647 S: a33 OK [URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg==] done
649 In this example, the server supports the INTERNAL mechanism and an
650 experimental mechanism called XSAMPLE, which also holds some
651 mechanism-specific data (the name "XSAMPLE" is for illustrative
652 purposes only).
654 BASE.7.4.GENURLAUTH. GENURLAUTH Response
656 Contents: One or more URLs
658 The GENURLAUTH response returns the URLAUTH-authorized URL(s)
659 requested by a GENURLAUTH command.
661 Example:
663 C: a777 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/
664 ;section=1.2;urlauth=submit+fred" INTERNAL
665 S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
666 ;urlauth=submit+fred:internal:91354a473744909de610943775f92038"
667 S: a777 OK GENURLAUTH completed
674 Crispin Standards Track [Page 12]
676 RFC 4467 IMAP - URLAUTH Extension May 2006
679 BASE.7.4.URLFETCH. URLFETCH Response
681 Contents: One or more URL/nstring pairs
683 The URLFETCH response returns the message text data associated with
684 one or more IMAP URLs, as described in [IMAPURL] and extended by this
685 document. This response occurs as the result of a URLFETCH command.
687 The returned data string is NIL if the URL is invalid for any reason
688 (including validation failure). If the URL is valid, but the IMAP
689 fetch of the body part returned NIL (this should not happen), the
690 returned data string should be the empty string ("") and not NIL.
692 Note: This command does not require that the URL refer to the
693 selected mailbox; nor does it require that any mailbox be
694 selected. It also does not in any way interfere with any selected
695 mailbox.
697 Example:
699 C: a002 URLFETCH "imap://joe@example.com/INBOX/;uid=20/
700 ;section=1.2;urlauth=submit+fred:internal
701 :91354a473744909de610943775f92038"
702 S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
703 ;urlauth=submit+fred:internal
704 :91354a473744909de610943775f92038" {28}
705 S: Si vis pacem, para bellum.
706 S:
707 S: a002 OK URLFETCH completed
709 9. Formal Syntax
711 The following syntax specification uses the Augmented Backus-Naur
712 Form (ABNF) notation as specified in [ABNF].
714 The following modifications are made to the Formal Syntax in [IMAP]:
716 resetkey = "RESETKEY" [SP mailbox *(SP mechanism)]
718 capability =/ "URLAUTH"
720 command-auth =/ resetkey / genurlauth / urlfetch
722 resp-text-code =/ "URLMECH" SP "INTERNAL" *(SP mechanism ["=" base64])
724 genurlauth = "GENURLAUTH" 1*(SP url-rump SP mechanism)
726 genurlauth-data = "*" SP "GENURLAUTH" 1*(SP url-full)
730 Crispin Standards Track [Page 13]
732 RFC 4467 IMAP - URLAUTH Extension May 2006
735 url-full = astring
736 ; contains authimapurlfull as defined below
738 url-rump = astring
739 ; contains authimapurlrump as defined below
741 urlfetch = "URLFETCH" 1*(SP url-full)
743 urlfetch-data = "*" SP "URLFETCH" 1*(SP url-full SP nstring)
745 The following extensions are made to the Formal Syntax in [IMAPURL]:
747 authimapurl = "imap://" enc-user [iauth] "@" hostport "/"
748 imessagepart
749 ; replaces "imapurl" and "iserver" rules for
750 ; URLAUTH authorized URLs
752 authimapurlfull = authimapurl iurlauth
754 authimapurlrump = authimapurl iurlauth-rump
756 enc-urlauth = 32*HEXDIG
758 enc-user = 1*achar
759 ; same as "enc_user" in RFC 2192
761 iurlauth = iurlauth-rump ":" mechanism ":" enc-urlauth
763 iurlauth-rump = [expire] ";URLAUTH=" access
765 access = ("submit+" enc-user) / ("user+" enc-user) /
766 "authuser" / "anonymous"
768 expire = ";EXPIRE=" date-time
769 ; date-time defined in [DATETIME]
771 mechanism = "INTERNAL" / 1*(ALPHA / DIGIT / "-" / ".")
772 ; case-insensitive
773 ; new mechanisms MUST be registered with IANA
786 Crispin Standards Track [Page 14]
788 RFC 4467 IMAP - URLAUTH Extension May 2006
791 10. Security Considerations
793 Security considerations are discussed throughout this memo.
795 The mailbox access key SHOULD have at least 128 bits of entropy
796 (refer to [RANDOM] for more details) and MUST be unpredictable.
798 The server implementation of the INTERNAL mechanism SHOULD consider
799 the possibility of needing to change the token generation algorithm,
800 and SHOULD incorporate some means of identifying the token generation
801 algorithm within the token.
803 The URLMECH status response code may expose sensitive data in the
804 mechanism-specific data for mechanisms other than INTERNAL. A server
805 implementation MUST implement a configuration that will not return a
806 URLMECH status response code unless some mechanism is provided that
807 protects the session from snooping, such as a TLS or SASL security
808 layer that provides confidentiality protection.
810 The calculation of an authorization token with a "plausible" key if
811 the mailbox can not be identified is necessary to avoid attacks in
812 which the server is probed to see if a particular mailbox exists on
813 the server by measuring the amount of time taken to reject a known
814 bad name versus some other name.
816 To protect against a computational denial-of-service attack, a server
817 MAY impose progressively longer delays on multiple URL requests that
818 fail validation.
820 The decision to use the "authuser" access identifier should be made
821 with caution. An "authuser" access identifier can be used by any
822 authorized user of the IMAP server; therefore, use of this access
823 identifier should be limited to content that may be disclosed to any
824 authorized user of the IMAP server.
826 The decision to use the "anonymous" access identifier should be made
827 with extreme caution. An "anonymous" access identifier can be used
828 by anyone; therefore, use of this access identifier should be limited
829 to content that may be disclosed to anyone. Many IMAP servers do not
830 permit anonymous access; in this case, the "anonymous" access
831 identifier is equivalent to "authuser", but this MUST NOT be relied
832 upon.
834 Although this specification does not prohibit the theoretical
835 capability to generate a URL with a server component other than the
836 logged in userid and server, this capability should only be provided
842 Crispin Standards Track [Page 15]
844 RFC 4467 IMAP - URLAUTH Extension May 2006
847 when the logged in userid/server has been authorized as equivalent to
848 the server component userid/server, or otherwise has access to that
849 userid/server mailbox access key table.
851 11. IANA Considerations
853 This document constitutes registration of the URLAUTH capability in
854 the imap4-capabilities registry.
856 URLAUTH authorization mechanisms are registered by publishing a
857 standards track or IESG-approved experimental RFC. The registry is
858 currently located at:
860 http://www.iana.org/assignments/urlauth-authorization-mechanism-registry
862 This registry is case-insensitive.
864 This document constitutes registration of the INTERNAL URLAUTH
865 authorization mechanism.
867 IMAP URLAUTH Authorization Mechanism Registry
869 Mechanism Name Reference
870 -------------- ---------
871 INTERNAL [RFC4467]
898 Crispin Standards Track [Page 16]
900 RFC 4467 IMAP - URLAUTH Extension May 2006
903 12. Normative References
905 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
906 Specifications: ABNF", RFC 4234, October 2005.
908 [BURL] Newman, C., "Message Submission BURL Extension", RFC 4468,
909 May 2006.
911 [DATETIME] Klyne, G. and C. Newman, "Date and Time on the Internet:
912 Timestamps", RFC 3339, July 2002.
914 [IMAP] Crispin, M., "Internet Message Access Protocol - Version
915 4rev1", RFC 3501, March 2003.
917 [IMAPURL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
919 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
920 Requirement Levels", BCP 14, RFC 2119, March 1997.
922 13. Informative References
924 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
925 Hashing for Message Authentication", RFC 2104, February
926 1997.
928 [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
929 "Randomness Requirements for Security", BCP 106, RFC 4086,
930 June 2005.
932 Author's Address
934 Mark R. Crispin
935 Networks and Distributed Computing
936 University of Washington
937 4545 15th Avenue NE
938 Seattle, WA 98105-4527
940 Phone: (206) 543-5762
941 EMail: MRC@CAC.Washington.EDU
954 Crispin Standards Track [Page 17]
956 RFC 4467 IMAP - URLAUTH Extension May 2006
959 Full Copyright Statement
961 Copyright (C) The Internet Society (2006).
963 This document is subject to the rights, licenses and restrictions
964 contained in BCP 78, and except as set forth therein, the authors
965 retain all their rights.
967 This document and the information contained herein are provided on an
968 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
969 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
970 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
971 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
972 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
973 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
975 Intellectual Property
977 The IETF takes no position regarding the validity or scope of any
978 Intellectual Property Rights or other rights that might be claimed to
979 pertain to the implementation or use of the technology described in
980 this document or the extent to which any license under such rights
981 might or might not be available; nor does it represent that it has
982 made any independent effort to identify any such rights. Information
983 on the procedures with respect to rights in RFC documents can be
984 found in BCP 78 and BCP 79.
986 Copies of IPR disclosures made to the IETF Secretariat and any
987 assurances of licenses to be made available, or the result of an
988 attempt made to obtain a general license or permission for the use of
989 such proprietary rights by implementers or users of this
990 specification can be obtained from the IETF on-line IPR repository at
991 http://www.ietf.org/ipr.
993 The IETF invites any interested party to bring to its attention any
994 copyrights, patents or patent applications, or other proprietary
995 rights that may cover technology that may be required to implement
996 this standard. Please address the information to the IETF at
997 ietf-ipr@ietf.org.
999 Acknowledgement
1001 Funding for the RFC Editor function is provided by the IETF
1002 Administrative Support Activity (IASA).
1010 Crispin Standards Track [Page 18]