idnits 2.17.1 draft-ncook-urlauth-accessid-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 338. 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 Copyright Line does not match the current year -- The document date (December 8, 2008) is 5618 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: 1 error (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Lemonade N. Cook 3 Internet-Draft Cloudmark 4 Intended status: Standards Track December 8, 2008 5 Expires: June 11, 2009 7 Internet Message Access Protocol (IMAP) - URL Access Identifier 8 Extension 9 draft-ncook-urlauth-accessid-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 11, 2009. 36 Abstract 38 The existing IMAP URL specification (RFC5092) lists several 39 identifiers and identifier prefixes, that can be used to 40 restrict access to URLAUTH-generated URLs. However, these 41 identifiers do not provide facilities for new services such as 42 streaming. This document proposes a set of new identifiers 43 as well as an IANA mechanism to register new identifiers for 44 future applications. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Conventions Used in this Document . . . . . . . . . . . . . . . 3 50 3. Additional Authorized Access Identifiers . . . . . . . . . . . 3 51 3.1. Existing Access Identifiers . . . . . . . . . . . . . . . . 3 52 3.2. Requirement for Additional Access Identifiers . . . . . . . 4 53 3.3. Additional Access Identifier Specification . . . . . . . . 4 54 3.4. Defining an access identifier for Streaming . . . . . . . . 5 55 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 58 6.1. Access Identifier Registration Template . . . . . . . . . . 6 59 6.2. Stream Application Registration . . . . . . . . . . . . . . 7 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 63 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 Intellectual Property and Copyright Statements . . . . . . . . . . 9 67 1. Introduction 69 The IMAP URL specification [RFC5092] provides a way to carry 70 authorization information in IMAP URLs. Several authorization 71 identifiers are specified in the document, which allow 72 URLAUTH-authorized URLs to be used only by anonymous users, 73 authenticated users, or message submission entities. However there 74 is no mechanism defined to create new identifiers, and 75 overloading the existing mechanisms has security as well as 76 administrative implications. 78 This document describes a new identifier "stream", to be 79 used by message streaming entities (as described in [STREAMING]), and 80 defines an IANA registration template, which can be used to register 81 new identifiers for future applications. 83 2. Conventions Used in this Document 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [RFC2119]. 89 In examples, "C:" and "S:" indicate lines sent by the client and 90 server respectively. If a single "C:" or "S:" label applies to 91 multiple lines, then some of the line breaks between those lines are 92 for editorial clarity only and may not be part of the actual protocol 93 exchange. 95 3. Additional Authorized Access Identifiers 97 3.1. Existing Access Identifiers 99 The IMAP URL specification, IMAPURL [RFC5092], specifies the 100 following authorized identifiers: 102 o "authuser" - Indicating that use of this URL is limited to 103 authenticated IMAP sessions that are logged in as any non- 104 anonymous user 106 o "anonymous" - Indicating that use of this URL is not restricted by 107 session authorization identity 109 Additionally the following identifier prefixes are defined: 111 o "submit+" - Followed by a userid, indicating that only a userid 112 authorized as a message submission entity on behalf of the 113 specified userid is permitted to use this URL 115 o "user+" - Followed by a userid, indicating that use of this URL is 116 limited to IMAP sessions that are logged in as the specified 117 userid 119 3.2. Requirement for Additional Access Identifiers 121 The existing identifiers are suitable for user-based 122 authorization, but only the "submit+" identifier prefix is 123 suitable for entities acting on behalf of a users, which is required 124 for new services such as streaming [STREAMING]. 126 The "submit+" identifier prefix is not suitable for use as a 127 general mechanism to grant access to entities acting on behalf of 128 users, for reasons that include: 130 o Security - The IMAP server maintains a list of submission server 131 entities that are entitled to retrieve IMAP URLs specifying the 132 "submit+" identifier prefix. If this list is extended to 133 include the set of all external entities that could act on behalf 134 of users, then the attack surface would be increased. 136 o Administration - When URLAUTH-style IMAP URLs are presented to an 137 IMAP server by entities acting on behalf of users, the server 138 administrator has no way of determining the intended use of that 139 URL from the server logs. 141 o Resourcing - Without a mechanism to distinguish between the 142 application for which an IMAP URL is to be used, the IMAP server 143 has no way to prioritize resources for particular applications. 144 For example, the server could prioritize "submit+" URL fetch 145 requests over other access identifiers. 147 3.3. Additional Access Identifier Specification 149 The previous section established that additional access identifiers 150 are required to support applications, such as streaming [STREAMING], 151 that require entities to retrieve URLAUTH URLs on behalf of users. 152 This section describes the scope and meaning of any additional 153 identifiers that are created. 155 Additional identifiers MUST take one of two forms (Section 4 156 gives the formal ABNF syntax): 158 o identifier - The name of the application e.g. "stream" 159 o identifier prefix - The name of the application e.g. 160 "stream+" followed by a user id. For example "stream+ncook". 162 In both cases, the semantics are the same as those for "submit+", 163 i.e. the identifier or identifier prefix (which 164 MUST be followed by a userid), indicates that only a userid 165 authorized as an application entity for the specified application is 166 permitted to use this URL. The IMAP server SHALL NOT validate any 167 specified userid but MUST validate that the IMAP session has an 168 authorization identity that is authorized as an application entity 169 for the specified application. The application entity itself MAY 170 choose to perform validation on any specified userid before 171 attempting to retrieve the URL. 173 The authorization granted by any identifiers used as 174 described above is self-describing, and so requires the IMAP server 175 to provide an extensible mechanism for associating userids with new 176 applications. For example, imgine a new application "foo" is 177 created, which requires application entities to retrieve URLs on 178 behalf of users. In this case, the IMAP server would need to provide 179 a way to register a new application "foo", and to associate the set 180 of userids to be used by those entities with the application "foo". 181 Any attempt to retrieve URLs containing the identifier "foo" 182 would be be checked for authorization against the list of userids 183 associated with the application "foo". 185 Section 6 provides the template required to register new 186 identifiers or prefixes with IANA. 188 3.4. Defining an access identifier for Streaming 190 One application that makes use of URLAUTH-authorized URLs is that of 191 streaming multimedia files received as internet messaging 192 attachments. This application is described in [STREAMING]. 194 See Section 6.2 for the IANA registration template for the "stream" 195 identifier. 197 4. Formal Syntax 199 The following syntax specification uses the Augmented Backus-Naur 200 Form (ABNF) notation as specified in [RFC5234]. 202 Except as noted otherwise, all alphabetic characters are case- 203 insensitive. The use of upper or lower case characters to define 204 token strings is for editorial clarity only. Implementations MUST 205 accept these strings in a case-insensitive fashion. 207 The ABNF specified below updates and replaces the formal syntax of 208 identifier as defined in IMAP URL [RFC5092]. 210 application = *ALPHA 212 access = ("submit+" enc-user) / ("user+" enc-user) / 213 "authuser" / "anonymous" / application / 214 (application "+" enc-user) 216 5. Acknowledgements 218 This document was inspired by discussions in the Lemonade Working 219 Group. 221 6. IANA Considerations 223 Access identifiers and prefixes MUST be specified in a standards 224 track or IESG approved experimental RFC. 226 6.1. Access Identifier Registration Template 228 To: iana@iana.org 229 Subject: IMAP URL Access Identifier Registration 231 Type: [Either "access identifier" or 232 "access prefix"] 234 Application: [Name of the application, e.g. "stream"] 236 Description: [A description of the application and its use 237 of IMAP URLs] 239 RFC Number: [Number of the RFC that the application was 240 defined in ] 242 Contact: [email and/or physical address to contact for 243 additional information] 245 6.2. Stream Application Registration 247 To: iana@iana.org 248 Subject: IMAP URL Access Identifier Registration 250 Type: access identifier 252 Application: stream 254 Description: Used by SIP Media Servers to retrieve 255 attachments for streaming to email 256 clients 258 RFC Number: This RFC 260 Contact: Neil Cook mailto:neil.cook@noware.co.uk 262 7. Security Considerations 264 The extension to identifiers specified in this document 265 provides a mechanism for extending the semantics of the "submit+" 266 prefix to arbitrary applications. The use of such 267 additional identifiers and prefixes is primarily for 268 security purposes, i.e. to prevent the overloading of "submit+" as a 269 generic mechanism to allow entities to retrieve IMAP URLs on behalf 270 of userids. However, the security implications are identical to that 271 discussed in Section 10.1 of IMAPURL [RFC5092]. 273 8. References 275 8.1. Normative References 277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 278 Requirement Levels", BCP 14, RFC 2119, March 1997. 280 [RFC5092] Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092, 281 November 2007. 283 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 284 Specifications: ABNF", STD 68, RFC 5234, January 2008. 286 8.2. Informative References 288 [STREAMING] 289 Cook, N., "Streaming Internet Messaging Attachments", 290 draft-ietf-lemonade-streaming-08.txt (Work in Progress) , 291 Dec 2008. 293 Author's Address 295 Neil L Cook 296 Cloudmark 298 Email: neil.cook@noware.co.uk 300 Full Copyright Statement 302 Copyright (C) The IETF Trust (2008). 304 This document is subject to the rights, licenses and restrictions 305 contained in BCP 78, and except as set forth therein, the authors 306 retain all their rights. 308 This document and the information contained herein are provided on an 309 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 310 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 311 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 312 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 313 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 314 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 316 Intellectual Property 318 The IETF takes no position regarding the validity or scope of any 319 Intellectual Property Rights or other rights that might be claimed to 320 pertain to the implementation or use of the technology described in 321 this document or the extent to which any license under such rights 322 might or might not be available; nor does it represent that it has 323 made any independent effort to identify any such rights. Information 324 on the procedures with respect to rights in RFC documents can be 325 found in BCP 78 and BCP 79. 327 Copies of IPR disclosures made to the IETF Secretariat and any 328 assurances of licenses to be made available, or the result of an 329 attempt made to obtain a general license or permission for the use of 330 such proprietary rights by implementers or users of this 331 specification can be obtained from the IETF on-line IPR repository at 332 http://www.ietf.org/ipr. 334 The IETF invites any interested party to bring to its attention any 335 copyrights, patents or patent applications, or other proprietary 336 rights that may cover technology that may be required to implement 337 this standard. Please address the information to the IETF at 338 ietf-ipr@ietf.org.