idnits 2.17.1 draft-ncook-urlauth-accessid-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5092, updated by this document, for RFC5378 checks: 2005-10-06) -- 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 (January 21, 2009) is 5546 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) == Outdated reference: A later version (-13) exists of draft-ietf-lemonade-streaming-08 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Lemonade N. Cook 3 Internet-Draft Cloudmark 4 Updates: 5092 (if approved) January 21, 2009 5 Intended status: Standards Track 6 Expires: July 25, 2009 8 Internet Message Access Protocol (IMAP) - URL Access Identifier 9 Extension 10 draft-ncook-urlauth-accessid-01 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and 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 Internet- 20 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 This Internet-Draft will expire on July 25, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 The existing IMAP URL specification (RFC 5092) lists several 50 identifiers and identifier prefixes, that can be used to 51 restrict access to URLAUTH-generated URLs. However, these 52 identifiers do not provide facilities for new services such as 53 streaming. This document proposes a set of new identifiers 54 as well as an IANA mechanism to register new identifiers for 55 future applications. 57 This document updates RFC 5092. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions Used in this Document . . . . . . . . . . . . . . 3 63 3. Additional Authorized Access Identifiers . . . . . . . . . . . 3 64 3.1. Existing Access Identifiers . . . . . . . . . . . . . . . 3 65 3.2. Requirement for Additional Access Identifiers . . . . . . 4 66 3.3. Additional Access Identifier Specification . . . . . . . . 4 67 3.4. Defining an access identifier for Streaming . . . . . . . 5 68 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 6.1. Access Identifier Registration Template . . . . . . . . . 6 72 6.2. Stream Application Registration . . . . . . . . . . . . . 7 73 6.3. Submit Application Registration . . . . . . . . . . . . . 7 74 6.4. User Application Registration . . . . . . . . . . . . . . 8 75 6.5. Authuser Application Registration . . . . . . . . . . . . 8 76 6.6. Anonymous Application Registration . . . . . . . . . . . . 9 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 The IMAP URL specification [RFC5092] provides a way to carry 86 authorization information in IMAP URLs. Several authorization 87 identifiers are specified in the document, which allow 88 URLAUTH-authorized URLs to be used only by anonymous users, 89 authenticated users, or message submission entities. However there 90 is no mechanism defined to create new identifiers, and 91 overloading the existing mechanisms has security as well as 92 administrative implications. 94 This document describes a new identifier "stream", to be 95 used by message streaming entities (as described in [STREAMING]), and 96 defines an IANA registration template, which can be used to register 97 new identifiers for future applications. IANA definitions 98 for the existing access identifiers and prefixes from RFC 5092 are 99 also defined in this document - this document updates RFC 5092 and 100 should be taken as the master in the event of any differences or 101 discrepancies. 103 2. Conventions Used in this Document 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 In examples, "C:" and "S:" indicate lines sent by the client and 110 server respectively. If a single "C:" or "S:" label applies to 111 multiple lines, then some of the line breaks between those lines are 112 for editorial clarity only and may not be part of the actual protocol 113 exchange. 115 3. Additional Authorized Access Identifiers 117 3.1. Existing Access Identifiers 119 The IMAP URL specification, IMAPURL [RFC5092], specifies the 120 following authorized identifiers: 122 o "authuser" - Indicating that use of this URL is limited to 123 authenticated IMAP sessions that are logged in as any non- 124 anonymous user 126 o "anonymous" - Indicating that use of this URL is not restricted by 127 session authorization identity 129 Additionally the following identifier prefixes are defined: 131 o "submit+" - Followed by a userid, indicating that only a userid 132 authorized as a message submission entity on behalf of the 133 specified userid is permitted to use this URL 135 o "user+" - Followed by a userid, indicating that use of this URL is 136 limited to IMAP sessions that are logged in as the specified 137 userid 139 3.2. Requirement for Additional Access Identifiers 141 The existing identifiers are suitable for user-based 142 authorization, but only the "submit+" identifier prefix is 143 suitable for entities acting on behalf of a user. Generic support 144 for external entities acting on behalf of users is required for new 145 services such as streaming [STREAMING]. 147 The "submit+" identifier prefix is not suitable for use as a 148 general mechanism to grant access to entities acting on behalf of 149 users, for reasons that include: 151 o Security - The IMAP server maintains a list of submission server 152 entities that are entitled to retrieve IMAP URLs specifying the 153 "submit+" identifier prefix. If this list is extended to 154 include the set of all external entities that could act on behalf 155 of users, then the attack surface would be increased. 157 o Administration - When URLAUTH-style IMAP URLs are presented to an 158 IMAP server by entities acting on behalf of users, the server 159 administrator has no way of determining the intended use of that 160 URL from the server logs. 162 o Resourcing - Without a mechanism to distinguish between the 163 application for which an IMAP URL is to be used, the IMAP server 164 has no way to prioritize resources for particular applications. 165 For example, the server could prioritize "submit+" URL fetch 166 requests over other access identifiers. 168 3.3. Additional Access Identifier Specification 170 The previous section established that additional access identifiers 171 are required to support applications, such as streaming [STREAMING], 172 that require entities to retrieve URLAUTH URLs on behalf of users. 173 This section describes the scope and meaning of any additional 174 identifiers that are created. 176 Additional identifiers MUST take one of two forms (Section 4 177 gives the formal ABNF syntax): 179 o identifier - The name of the application e.g. "stream" 181 o identifier prefix - The name of the application e.g. 182 "stream" followed by a "+" and then a userid. For example 183 "stream+testuser". 185 In both cases, the semantics are the same as those for "submit+", 186 i.e. the identifier or identifier prefix (which 187 MUST be followed by a userid), indicates that only a userid 188 authorized as an application entity for the specified application is 189 permitted to use this URL. In the case of identifier 190 prefixes, the IMAP server SHALL NOT validate the specified userid but 191 MUST validate that the IMAP session has an authorization identity 192 that is authorized as an application entity for the specified 193 application. The application entity itself MAY choose to perform 194 validation on any specified userid before attempting to retrieve the 195 URL. 197 The authorization granted by any identifiers used as 198 described above is self-describing, and so requires the IMAP server 199 to provide an extensible mechanism for associating userids with new 200 applications. For example, imagine a new application "foo" is 201 created, which requires application entities to retrieve URLs on 202 behalf of users. In this case, the IMAP server would need to provide 203 a way to register a new application "foo", and to associate the set 204 of userids to be used by those entities with the application "foo". 205 Any attempt to retrieve URLs containing the identifier "foo" 206 would be checked for authorization against the list of userids 207 associated with the application "foo". 209 Section 6 provides the template required to register new 210 identifiers or prefixes with IANA. 212 3.4. Defining an access identifier for Streaming 214 One application that makes use of URLAUTH-authorized URLs is that of 215 streaming multimedia files received as internet messaging 216 attachments. This application is described in [STREAMING]. 218 See Section 6.2 for the IANA registration template for the "stream" 219 identifier. 221 4. Formal Syntax 223 The following syntax specification uses the Augmented Backus-Naur 224 Form (ABNF) notation as specified in [RFC5234]. 226 Except as noted otherwise, all alphabetic characters are case- 227 insensitive. The use of upper or lower case characters to define 228 token strings is for editorial clarity only. Implementations MUST 229 accept these strings in a case-insensitive fashion. 231 The ABNF specified below updates the formal syntax of 232 identifier as defined in IMAP URL [RFC5092]. 234 application = 1*(ALPHA/DIGIT) 236 access =/ application / (application "+" enc-user) 238 5. Acknowledgements 240 This document was inspired by discussions in the Lemonade Working 241 Group. 243 6. IANA Considerations 245 Access identifiers and prefixes MUST be specified in a standards 246 track or IESG approved experimental RFC. This section gives the IAN 247 registration entries for the existing access identifiers and prefixes 248 from RFC 5092 as well as the entry for the "stream" application. 250 6.1. Access Identifier Registration Template 252 To: iana@iana.org 253 Subject: IMAP URL Access Identifier Registration 255 Type: [Either " identifier" or 256 " identifier prefix"] 258 Application: [Name of the application, e.g. "stream"] 260 Description: [A description of the application and its use 261 of IMAP URLs] 263 RFC Number: [Number of the RFC that the application was 264 defined in ] 266 Contact: [email and/or physical address to contact for 267 additional information] 269 6.2. Stream Application Registration 271 To: iana@iana.org 272 Subject: IMAP URL Access Identifier Registration 274 Type: identifier 276 Application: stream 278 Description: Used by SIP Media Servers to retrieve 279 attachments for streaming to email 280 clients 282 RFC Number: This RFC 284 Contact: Neil Cook mailto:neil.cook@noware.co.uk 286 6.3. Submit Application Registration 288 To: iana@iana.org 289 Subject: IMAP URL Access Identifier Registration 291 Type: identifier prefix 293 Application: submit 295 Description: Used by message submission entities to 296 retrieve attachments to be included in 297 submitted messages 299 RFC Number: This RFC 301 Contact: Neil Cook mailto:neil.cook@noware.co.uk 303 6.4. User Application Registration 305 To: iana@iana.org 306 Subject: IMAP URL Access Identifier Registration 308 Type: identifier prefix 310 Application: user 312 Description: Used to restrict access to to IMAP sessions 313 that are logged in as the specified userid 315 RFC Number: This RFC 317 Contact: Neil Cook mailto:neil.cook@noware.co.uk 319 6.5. Authuser Application Registration 321 To: iana@iana.org 322 Subject: IMAP URL Access Identifier Registration 324 Type: identifier 326 Application: authuser 328 Description: Used to restrict access to to IMAP sessions 329 that are logged in as any non-anonymous 330 user of that IMAP server 332 RFC Number: This RFC 334 Contact: Neil Cook mailto:neil.cook@noware.co.uk 336 6.6. Anonymous Application Registration 338 To: iana@iana.org 339 Subject: IMAP URL Access Identifier Registration 341 Type: identifier 343 Application: anonymous 345 Description: Indicates that use of this URL is 346 not restricted by session authorization 347 identity 349 RFC Number: This RFC 351 Contact: Neil Cook mailto:neil.cook@noware.co.uk 353 7. Security Considerations 355 The extension to identifiers specified in this document 356 provides a mechanism for extending the semantics of the "submit+" 357 prefix to arbitrary applications. The use of such 358 additional identifiers and prefixes is primarily for 359 security purposes, i.e. to prevent the overloading of "submit+" as a 360 generic mechanism to allow entities to retrieve IMAP URLs on behalf 361 of userids. Other than this, the security implications are identical 362 to those discussed in Section 10.1 of IMAPURL [RFC5092]. 364 8. References 366 8.1. Normative References 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, March 1997. 371 [RFC5092] Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092, 372 November 2007. 374 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 375 Specifications: ABNF", STD 68, RFC 5234, January 2008. 377 8.2. Informative References 379 [STREAMING] 380 Cook, N., "Streaming Internet Messaging Attachments", 381 draft-ietf-lemonade-streaming-08.txt (Work in Progress) , 382 Dec 2008. 384 Author's Address 386 Neil L Cook 387 Cloudmark 389 Email: neil.cook@noware.co.uk