idnits 2.17.1 draft-ietf-sasl-anon-05.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 3667, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 344. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 351. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 357. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 363), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (21 February 2005) is 7004 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) == Missing Reference: 'RFC3629' is mentioned on line 237, but not defined == Missing Reference: 'Stringprep' is mentioned on line 258, but not defined ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2822 (ref. 'IMAIL') (Obsoleted by RFC 5322) -- No information found for draft-ietf-sasl-rfc2222bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASL' ** Obsolete normative reference: RFC 3454 (ref. 'StringPrep') (Obsoleted by RFC 7564) -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Editor: Kurt D. Zeilenga 3 Intended Category: Standards Track OpenLDAP Foundation 4 Expires: August 2005 21 February 2005 5 Obsoletes: RFC 2245 7 The Anonymous SASL Mechanism 8 10 Status of Memo 12 This document is intended to be, after appropriate review and 13 revision, submitted to the RFC Editor as a Standards Track document. 14 Distribution of this memo is unlimited. Technical discussion of this 15 document will take place on the IETF SASL mailing list 16 . Please send editorial comments directly to the 17 document editor . 19 By submitting this Internet-Draft, I accept the provisions of Section 20 4 of RFC 3667. By submitting this Internet-Draft, I certify that any 21 applicable patent or other IPR claims of which I am aware have been 22 disclosed, or will be disclosed, and any of which I become aware will 23 be disclosed, in accordance with RFC 3668. 25 Internet-Drafts are working documents of the Internet Engineering Task 26 Force (IETF), its areas, and its working groups. Note that other 27 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference material 32 or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright (C) The Internet Society (2005). All Rights Reserved. 42 Please see the Full Copyright section near the end of this document 43 for more information. 45 Abstract 47 It is common practice on the Internet to permit anonymous access to 48 various services. Traditionally, this has been done with a plain text 49 password mechanism using "anonymous" as the user name and optional 50 trace information, such as an email address, as the password. As 51 plain text login commands are not permitted in new IETF protocols, a 52 new way to provide anonymous login is needed within the context of the 53 Simple Authentication and Security Layer (SASL) framework. 55 1. Anonymous SASL mechanism 57 This document defines an anonymous mechanism for the Simple 58 Authentication and Security Layer ([SASL]) framework. The name 59 associated with this mechanism is "ANONYMOUS". 61 Unlike many other SASL mechanisms whose purpose is to authenticate and 62 identify the user to a server, the purpose of this SASL mechanism is 63 to allow the user to gain access to services or resources without 64 requiring the user to establish or otherwise disclose their identity 65 to the server. That is, this mechanism provides an anonymous login 66 method. 68 This mechanism does not provide a security layer. 70 This document replaces RFC 2245. Changes since RFC 2245 are detailed 71 in Appendix A. 73 The mechanism consists of a single message from the client to the 74 server. The client may include in this message trace information in 75 the form of a string of [UTF-8] encoded [Unicode] characters prepared 76 in accordance with [StringPrep] and the "trace" stringprep profile 77 defined in Section 2 of this document. The trace information, which 78 has no semantical value, should take one of two forms: an Internet 79 email address, an opaque string which does not contain the '@' 80 (U+0040) character and can be interpreted by the system administrator 81 of the client's domain. For privacy reasons, an Internet email 82 address or other information identifying the user should only be used 83 with permission from the user. 85 A server which permits anonymous access will announce support for the 86 ANONYMOUS mechanism, and allow anyone to log in using that mechanism, 87 usually with restricted access. 89 A formal grammar for the client message using Augmented BNF [ABNF] is 90 provide below as a tool for understanding this technical 91 specification. 93 message = [ email / token ] 94 ;; to be prepared in accordance with Section 2 96 UTF1 = %x00-3F / %x41-7F ;; less '@' (U+0040) 97 UTF2 = %xC2-DF UTF0 98 UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / 99 %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) 100 UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / 101 %xF4 %x80-8F 2(UTF0) 102 UTF0 = %x80-BF 104 TCHAR = UTF1 / UTF2 / UTF3 / UTF4 105 ;; any UTF-8 encoded Unicode character 106 ;; except '@' (U+0040) 108 email = addr-spec 109 ;; as defined in [IMAIL] 111 token = 1*255TCHAR 113 Note to implementors: 114 The production is restricted to 255 UTF-8 encoded Unicode 115 characters. As the encoding of a characters uses a sequence of 1 116 to 4 octets, a token may be long as 1020 octets. 118 2. The "trace" profile of "Stringprep" 120 This section defines the "trace" profile of [StringPrep]. This 121 profile is designed for use with the SASL ANONYMOUS Mechanism. 122 Specifically, the client is to prepare the production in 123 accordance with this profile. 125 The character repertoire of this profile is Unicode 3.2 [Unicode]. 127 No mapping is required by this profile. 129 No Unicode normalization is required by this profile. 131 The list of unassigned code points for this profile is that provided 132 in appendix A of [StringPrep]. Unassigned code points are not 133 prohibited. 135 Characters from the following tables of [StringPrep] are prohibited: 136 - C.2.1 (ASCII control characters) 137 - C.2.2 (Non-ASCII control characters) 138 - C.3 (Private use characters) 139 - C.4 (Non-character code points) 140 - C.5 (Surrogate codes) 141 - C.6 (Inappropriate for plain text) 142 - C.8 (Change display properties are deprecated) 143 - C.9 (Tagging characters) 145 No additional characters are prohibited. 147 This profile requires bidirectional character checking per Section 6 148 of [StringPrep]. 150 3. Example 152 Here is a sample ANONYMOUS login between an IMAP client and server. 153 In this example, "C:" and "S:" indicate lines sent by the client and 154 server respectively. If such lines are wrapped without a new "C:" or 155 "S:" label, then the wrapping is for editorial clarity and is not part 156 of the command. 158 Note that this example uses the IMAP profile [IMAP4] of SASL. The 159 base64 encoding of challenges and responses, as well as the "+ " 160 preceding the responses are part of the IMAP4 profile, not part of 161 SASL itself. Additionally, protocols with SASL profiles permitting an 162 initial client response will be able to avoid the extra round trip 163 below (the server response with an empty "+ "). 165 In this example, the trace information is "sirhc". 167 S: * OK IMAP4 server ready 168 C: A001 CAPABILITY 169 S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=DIGEST-MD5 AUTH=ANONYMOUS 170 S: A001 OK done 171 C: A002 AUTHENTICATE ANONYMOUS 172 S: + 173 C: c2lyaGM= 174 S: A003 OK Welcome, trace information has been logged. 176 4. Security Considerations 178 The ANONYMOUS mechanism grants access to services and/or resources by 179 anyone. For this reason it should be disabled by default so the 180 administrator can make an explicit decision to enable it. 182 If the anonymous user has any write privileges, a denial of service 183 attack is possible by filling up all available space. This can be 184 prevented by disabling all write access by anonymous users. 186 If anonymous users have read and write access to the same area, the 187 server can be used as a communication mechanism to anonymously 188 exchange information. Servers which accept anonymous submissions 189 should implement the common "drop box" model which forbids anonymous 190 read access to the area where anonymous submissions are accepted. 192 If the anonymous user can run many expensive operations (e.g., an IMAP 193 SEARCH BODY command), this could enable a denial of service attack. 194 Servers are encouraged to reduce the priority of anonymous users or 195 limit their resource usage. 197 While servers may impose a limit on the number of anonymous users, it 198 is noted that such limits enable denial of service attacks and should 199 be used with caution. 201 The trace information is not authenticated so it can be falsified. 202 This can be used as an attempt to get someone else in trouble for 203 access to questionable information. Administrators investigating 204 abuse need to realize this trace information may be falsified. 206 A client which uses the user's correct email address as trace 207 information without explicit permission may violate that user's 208 privacy. Anyone who accesses an anonymous archive on a sensitive 209 subject (e.g. sexual abuse) likely has strong privacy needs. Clients 210 should not send the email address without explicit permission of the 211 user and should offer the option of supplying no trace information -- 212 thus only exposing the source IP address and time. Anonymous proxy 213 servers could enhance this privacy, but would have to consider the 214 resulting potential denial of service attacks. 216 Anonymous connections are susceptible to man-in-the-middle attacks 217 which view or alter the data transferred. Clients and servers are 218 encouraged to support external data security services. 220 Protocols which fail to require an explicit anonymous login are more 221 susceptible to break-ins given certain common implementation 222 techniques. Specifically, Unix servers which offer user login may 223 initially start up as root and switch to the appropriate user id after 224 an explicit login command. Normally such servers refuse all data 225 access commands prior to explicit login and may enter a restricted 226 security environment (e.g., the Unix chroot(2) function) for anonymous 227 users. If anonymous access is not explicitly requested, the entire 228 data access machinery is exposed to external security attacks without 229 the chance for explicit protective measures. Protocols which offer 230 restricted data access should not allow anonymous data access without 231 an explicit login step. 233 General [SASL] security considerations apply to this mechanism. 235 [StringPrep] security considerations as well as [Unicode] security 236 considerations discussed in [StringPrep] apply to this mechanism. 237 UTF-8 [RFC3629] security considerations also apply. 239 5. IANA Considerations 241 It is requested that the SASL Mechanism registry [IANA-SASL] entry for 242 the ANONYMOUS mechanism be updated to reflect that this document now 243 provides its technical specification. 245 To: iana@iana.org 246 Subject: Updated Registration of SASL mechanism ANONYMOUS 248 SASL mechanism name: ANONYMOUS 249 Security considerations: See RFC XXXX. 250 Published specification (optional, recommended): RFC XXXX 251 Person & email address to contact for further information: 252 Kurt Zeilenga 253 Chris Newman 254 Intended usage: COMMON 255 Author/Change controller: IESG 256 Note: Updates existing entry for ANONYMOUS 258 It is requested that the [Stringprep] profile "trace", first defined 259 in this RFC, be registered: 261 To: iana@iana.org 262 Subject: Initial Registration of Stringprep "trace" profile 264 Stringprep profile: trace 265 Published specification: RFC XXXX 266 Person & email address to contact for further information: 267 Kurt Zeilenga 269 6. Acknowledgment 271 This document is a revision of RFC 2245 by Chris Newman. Portions of 272 the grammar defined in Section 1 were borrowed from RFC 3629 by 273 Francois Yergeau. 275 This document is a product of the IETF SASL WG. 277 7. Normative References 279 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 280 Specifications: ABNF", RFC 2234, November 1997. 282 [IMAIL] Resnick, P., Ed., "Internet Message Format", RFC 2822, 283 April 2001. 285 [SASL] Melnikov, A. (Editor), "Simple Authentication and 286 Security Layer (SASL)", 287 draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. 289 [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of 290 Internationalized Strings ('stringprep')", RFC 3454, 291 December 2002. 293 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 294 3.2.0" is defined by "The Unicode Standard, Version 3.0" 295 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 296 as amended by the "Unicode Standard Annex #27: Unicode 297 3.1" (http://www.unicode.org/reports/tr27/) and by the 298 "Unicode Standard Annex #28: Unicode 3.2" 299 (http://www.unicode.org/reports/tr28/). 301 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 302 10646", RFC 3629 (also STD 63), November 2003. 304 8. Informative References 306 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 307 4rev1", RFC 3501, March 2003. 309 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) 310 MECHANISMS", 311 . 313 9. Editor's Address 315 Kurt D. Zeilenga 316 OpenLDAP Foundation 318 Email: Kurt@OpenLDAP.org 320 Appendix A. Changes since RFC 2245 322 This appendix is non-normative. 324 RFC 2245 allows the client to include optional trace information in 325 the form of a human readable string. RFC 2245 restricted this string 326 to US-ASCII. As the Internet is international, this document uses a 327 string restricted to UTF-8 encoded Unicode characters. A "stringprep" 328 profile is defined to precisely define which Unicode characters are 329 allowed in this string. While the string remains restricted to 255 330 characters, the encoded length of each character may now range from 1 331 to 4 octets. 333 Additionally, a number of editorial changes were made. 335 Intellectual Property Rights 337 The IETF takes no position regarding the validity or scope of any 338 Intellectual Property Rights or other rights that might be claimed to 339 pertain to the implementation or use of the technology described in 340 this document or the extent to which any license under such rights 341 might or might not be available; nor does it represent that it has 342 made any independent effort to identify any such rights. Information 343 on the procedures with respect to rights in RFC documents can be found 344 in BCP 78 and BCP 79. 346 Copies of IPR disclosures made to the IETF Secretariat and any 347 assurances of licenses to be made available, or the result of an 348 attempt made to obtain a general license or permission for the use of 349 such proprietary rights by implementers or users of this specification 350 can be obtained from the IETF on-line IPR repository at 351 http://www.ietf.org/ipr. 353 The IETF invites any interested party to bring to its attention any 354 copyrights, patents or patent applications, or other proprietary 355 rights that may cover technology that may be required to implement 356 this standard. Please address the information to the IETF at 357 ietf-ipr@ietf.org. 359 Full Copyright 361 Copyright (C) The Internet Society (2005). This document is subject 362 to the rights, licenses and restrictions contained in BCP 78, and 363 except as set forth therein, the authors retain all their rights. 365 This document and the information contained herein are provided on an 366 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 367 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 368 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 369 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 370 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 371 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.