idnits 2.17.1 draft-ncook-urlauth-accessid-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 10, 2009) is 5518 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-10 Summary: 1 error (**), 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) March 10, 2009 5 Intended status: Standards Track 6 Expires: September 11, 2009 8 Internet Message Access Protocol (IMAP) - URL Access Identifier 9 Extension 10 draft-ncook-urlauth-accessid-02 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. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on September 11, 2009. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 The existing IMAP URL specification (RFC 5092) lists several 59 identifiers and identifier prefixes, that can be used to 60 restrict access to URLAUTH-generated URLs. However, these 61 identifiers do not provide facilities for new services such as 62 streaming. This document proposes a set of new identifiers 63 as well as an IANA mechanism to register new identifiers for 64 future applications. 66 This document updates RFC 5092. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Conventions Used in this Document . . . . . . . . . . . . . . 4 72 3. Additional Authorized Access Identifiers . . . . . . . . . . . 4 73 3.1. Existing Access Identifiers . . . . . . . . . . . . . . . 4 74 3.2. Requirement for Additional Access Identifiers . . . . . . 5 75 3.3. Additional Access Identifier Specification . . . . . . . . 5 76 3.4. Defining an access identifier for Streaming . . . . . . . 6 77 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6 78 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 80 6.1. Access Identifier Registration Template . . . . . . . . . 8 81 6.2. Stream Application Registration . . . . . . . . . . . . . 8 82 6.3. Submit Application Registration . . . . . . . . . . . . . 9 83 6.4. User Application Registration . . . . . . . . . . . . . . 9 84 6.5. Authuser Application Registration . . . . . . . . . . . . 10 85 6.6. Anonymous Application Registration . . . . . . . . . . . . 10 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 89 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 92 1. Introduction 94 The IMAP URL specification [RFC5092] provides a way to carry 95 authorization information in IMAP URLs. Several authorization 96 identifiers are specified in the document, which allow 97 URLAUTH-authorized URLs to be used only by anonymous users, 98 authenticated users, or message submission entities. However there 99 is no mechanism defined to create new identifiers, and 100 overloading the existing mechanisms has security as well as 101 administrative implications. 103 This document describes a new identifier "stream", to be 104 used by message streaming entities (as described in [STREAMING]), and 105 defines an IANA registration template, which can be used to register 106 new identifiers for future applications. IANA definitions 107 for the existing access identifiers and prefixes from RFC 5092 are 108 also defined in this document - this document updates RFC 5092 and 109 should be taken as the master in the event of any differences or 110 discrepancies. 112 2. Conventions Used in this Document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 In examples, "C:" and "S:" indicate lines sent by the client and 119 server respectively. If a single "C:" or "S:" label applies to 120 multiple lines, then some of the line breaks between those lines are 121 for editorial clarity only and may not be part of the actual protocol 122 exchange. 124 3. Additional Authorized Access Identifiers 126 3.1. Existing Access Identifiers 128 The IMAP URL specification, IMAPURL [RFC5092], specifies the 129 following authorized identifiers: 131 o "authuser" - Indicating that use of this URL is limited to 132 authenticated IMAP sessions that are logged in as any non- 133 anonymous user 135 o "anonymous" - Indicating that use of this URL is not restricted by 136 session authorization identity 138 Additionally the following identifier prefixes are defined: 140 o "submit+" - Followed by a userid, indicating that only a userid 141 authorized as a message submission entity on behalf of the 142 specified userid is permitted to use this URL 144 o "user+" - Followed by a userid, indicating that use of this URL is 145 limited to IMAP sessions that are logged in as the specified 146 userid 148 3.2. Requirement for Additional Access Identifiers 150 The existing identifiers are suitable for user-based 151 authorization, but only the "submit+" identifier prefix is 152 suitable for entities acting on behalf of a user. Generic support 153 for external entities acting on behalf of users is required for new 154 services such as streaming [STREAMING]. 156 The "submit+" identifier prefix is not suitable for use as a 157 general mechanism to grant access to entities acting on behalf of 158 users, for reasons that include: 160 o Security - The IMAP server maintains a list of submission server 161 entities that are entitled to retrieve IMAP URLs specifying the 162 "submit+" identifier prefix. If this list is extended to 163 include the set of all external entities that could act on behalf 164 of users, then the attack surface would be increased. 166 o Administration - When URLAUTH-style IMAP URLs are presented to an 167 IMAP server by entities acting on behalf of users, the server 168 administrator has no way of determining the intended use of that 169 URL from the server logs. 171 o Resourcing - Without a mechanism to distinguish between the 172 application for which an IMAP URL is to be used, the IMAP server 173 has no way to prioritize resources for particular applications. 174 For example, the server could prioritize "submit+" URL fetch 175 requests over other access identifiers. 177 3.3. Additional Access Identifier Specification 179 The previous section established that additional access identifiers 180 are required to support applications, such as streaming [STREAMING], 181 that require entities to retrieve URLAUTH URLs on behalf of users. 182 This section describes the scope and meaning of any additional 183 identifiers that are created. 185 Additional identifiers MUST take one of two forms (Section 4 186 gives the formal ABNF syntax): 188 o identifier - The name of the application e.g. "stream" 190 o identifier prefix - The name of the application e.g. 191 "stream" followed by a "+" and then a userid. For example 192 "stream+testuser". 194 In both cases, the semantics are the same as those for "submit+", 195 i.e. the identifier or identifier prefix (which 196 MUST be followed by a userid), indicates that only a userid 197 authorized as an application entity for the specified application is 198 permitted to use this URL. In the case of identifier 199 prefixes, the IMAP server SHALL NOT validate the specified userid but 200 MUST validate that the IMAP session has an authorization identity 201 that is authorized as an application entity for the specified 202 application. The application entity itself MAY choose to perform 203 validation on any specified userid before attempting to retrieve the 204 URL. 206 The authorization granted by any identifiers used as 207 described above is self-describing, and so requires the IMAP server 208 to provide an extensible mechanism for associating userids with new 209 applications. For example, imagine a new application "foo" is 210 created, which requires application entities to retrieve URLs on 211 behalf of users. In this case, the IMAP server would need to provide 212 a way to register a new application "foo", and to associate the set 213 of userids to be used by those entities with the application "foo". 214 Any attempt to retrieve URLs containing the identifier "foo" 215 would be checked for authorization against the list of userids 216 associated with the application "foo". 218 Section 6 provides the template required to register new 219 identifiers or prefixes with IANA. 221 3.4. Defining an access identifier for Streaming 223 One application that makes use of URLAUTH-authorized URLs is that of 224 streaming multimedia files received as internet messaging 225 attachments. This application is described in [STREAMING]. 227 See Section 6.2 for the IANA registration template for the "stream" 228 identifier. 230 4. Formal Syntax 232 The following syntax specification uses the Augmented Backus-Naur 233 Form (ABNF) notation as specified in [RFC5234]. 235 Except as noted otherwise, all alphabetic characters are case- 236 insensitive. The use of upper or lower case characters to define 237 token strings is for editorial clarity only. Implementations MUST 238 accept these strings in a case-insensitive fashion. 240 The ABNF specified below updates the formal syntax of 241 identifier as defined in IMAP URL [RFC5092]. 243 application = 1*(ALPHA/DIGIT) 245 access =/ application / (application "+" enc-user) 247 5. Acknowledgements 249 This document was inspired by discussions in the Lemonade Working 250 Group. 252 6. IANA Considerations 254 IANA is requested to create a new registry for IMAP URLAUTH access 255 identifiers and prefixes. 257 Access identifiers and prefixes MUST be specified in a standards 258 track or IESG approved experimental RFC. This section gives the IANA 259 registration entries for the existing access identifiers and prefixes 260 from RFC 5092 as well as the entry for the "stream" application. 262 6.1. Access Identifier Registration Template 264 To: iana@iana.org 265 Subject: IMAP URL Access Identifier Registration 267 Type: [Either " identifier" or 268 " identifier prefix"] 270 Application: [Name of the application, e.g. "stream"] 272 Description: [A description of the application and its use 273 of IMAP URLs] 275 RFC Number: [Number of the RFC that the application was 276 defined in ] 278 Contact: [email and/or physical address to contact for 279 additional information] 281 6.2. Stream Application Registration 283 To: iana@iana.org 284 Subject: IMAP URL Access Identifier Registration 286 Type: identifier 288 Application: stream 290 Description: Used by SIP Media Servers to retrieve 291 attachments for streaming to email 292 clients 294 RFC Number: This RFC 296 Contact: mailto:neil.cook@noware.co.uk 298 6.3. Submit Application Registration 300 To: iana@iana.org 301 Subject: IMAP URL Access Identifier Registration 303 Type: identifier prefix 305 Application: submit 307 Description: Used by message submission entities to 308 retrieve attachments to be included in 309 submitted messages 311 RFC Number: This RFC 313 Contact: Lemonade WG mailto:lemonade@ietf.org 315 6.4. User Application Registration 317 To: iana@iana.org 318 Subject: IMAP URL Access Identifier Registration 320 Type: identifier prefix 322 Application: user 324 Description: Used to restrict access to to IMAP sessions 325 that are logged in as the specified userid 327 RFC Number: This RFC 329 Contact: Lemonade WG mailto:lemonade@ietf.org 331 6.5. Authuser Application Registration 333 To: iana@iana.org 334 Subject: IMAP URL Access Identifier Registration 336 Type: identifier 338 Application: authuser 340 Description: Used to restrict access to to IMAP sessions 341 that are logged in as any non-anonymous 342 user of that IMAP server 344 RFC Number: This RFC 346 Contact: Lemonade WG mailto:lemonade@ietf.org 348 6.6. Anonymous Application Registration 350 To: iana@iana.org 351 Subject: IMAP URL Access Identifier Registration 353 Type: identifier 355 Application: anonymous 357 Description: Indicates that use of this URL is 358 not restricted by session authorization 359 identity 361 RFC Number: This RFC 363 Contact: Lemonade WG mailto:lemonade@ietf.org 365 7. Security Considerations 367 The extension to identifiers specified in this document 368 provides a mechanism for extending the semantics of the "submit+" 369 prefix to arbitrary applications. The use of such 370 additional identifiers and prefixes is primarily for 371 security purposes, i.e. to prevent the overloading of "submit+" as a 372 generic mechanism to allow entities to retrieve IMAP URLs on behalf 373 of userids. Other than this, the security implications are identical 374 to those discussed in Section 10.1 of IMAPURL [RFC5092]. 376 8. References 378 8.1. Normative References 380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 381 Requirement Levels", BCP 14, RFC 2119, March 1997. 383 [RFC5092] Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092, 384 November 2007. 386 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 387 Specifications: ABNF", STD 68, RFC 5234, January 2008. 389 8.2. Informative References 391 [STREAMING] 392 Cook, N., "Streaming Internet Messaging Attachments", 393 draft-ietf-lemonade-streaming-10.txt (Work in Progress) , 394 Dec 2008. 396 Author's Address 398 Neil L Cook 399 Cloudmark 401 Email: neil.cook@noware.co.uk