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