From owner-ietf-sasl Tue Feb 11 03:50:11 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1BBoBT13831 for ietf-sasl-bks; Tue, 11 Feb 2003 03:50:11 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BBoAd13827 for ; Tue, 11 Feb 2003 03:50:10 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28775; Tue, 11 Feb 2003 06:46:27 -0500 (EST) Message-Id: <200302111146.GAA28775@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-plain-00.txt Date: Tue, 11 Feb 2003 06:46:27 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The Plain SASL Mechanism Author(s) : K. Zeilenga Filename : draft-ietf-sasl-plain-00.txt Pages : 8 Date : 2003-2-10 This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols which lack a simple password authentication command. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-plain-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-plain-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-plain-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-10135953.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-plain-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-plain-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-10135953.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Wed Feb 19 12:13:18 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1JKDIT07214 for ietf-sasl-bks; Wed, 19 Feb 2003 12:13:18 -0800 (PST) Received: from konishi-polis.mit.edu (STRATTON-FOUR-THIRTY-FOUR.MIT.EDU [18.187.6.179]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1JKDHd07209 for ; Wed, 19 Feb 2003 12:13:17 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id B64EF151F11; Wed, 19 Feb 2003 15:13:18 -0500 (EST) To: ietf-sasl@imc.org Subject: Last call for draft-ietf-sasl-anon-00 From: Sam Hartman Date: Wed, 19 Feb 2003 15:13:18 -0500 Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message initiates a SASL Working Group Last Call on the document: Title : The Anonymous SASL Mechanism Editor : K. Zeilenga Filename : draft-ietf-sasl-anon-00.txt The purpose of this WG Last Call is to ensure that the Working Group has achieved consensus that the document is suitable for publication as a Proposed Standard. Please review the document for both technical and editorial problems. Technical issues should be discussed on this list. Editorial issues may be sent to the document editor. The Last Call period will end on Wednesday, March 5, 2003. Upon completion of the last call, the WG chair(s) will take action based upon the consensus of the WG. Possible actions include: 1) recommending to the IETF Security Area Directors that the document, after possible editorial or other minor changes, be considered by the IESG for publication as a Standard Track RFC (which generally involves an IETF-wide Last Call); or 2) requiring that outstanding issues be adequately addressed prior to further action (including, possibly, another WG Last Call). Remember that it is our responsibility as Working Group members to ensure the quality of our documents and of the Internet Standards process. So, please read and comment! - Sam Hartman SASL co-chair From owner-ietf-sasl Thu Feb 20 00:06:03 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1K863G07744 for ietf-sasl-bks; Thu, 20 Feb 2003 00:06:03 -0800 (PST) Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1K862d07739 for ; Thu, 20 Feb 2003 00:06:02 -0800 (PST) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h1K861G17425 for ; Thu, 20 Feb 2003 00:06:01 -0800 (PST) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.6/8.11.6) with ESMTP id h1K87JV13985 for ; Thu, 20 Feb 2003 00:07:19 -0800 (PST) Message-Id: <200302200807.h1K87JV13985@katroo.Sendmail.COM> To: ietf-sasl@imc.org Subject: comments on draft-ietf-sasl-anon-00 Date: Wed, 19 Feb 2003 23:54:04 -0800 From: Philip Guenther Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The syntax for UTF-8 characters in the draft permits "non-shortest form" encodings and encodings for characters outside the range of the Unicode character set. Neither may be interpreted by a program conforming to the Unicode 3.2 specification, which the draft references. Paragraph 5 of section 4 (security consideration), suggests the use of an idle timeout on servers that place a limit on the number of concurrent anonymous users in order to combat a denial-of-service attack. As keeping a connection from being considered idle will generally require simply sending a request (possibly even a malformed request), it's unlikely that an idle timeout will actually prevent an intentional DOS attack from succeeding. A hard timeout on connection duration, network access limitations, or (where appropriate) a limit on the number of requests permitted on an anonymous connection may be required to provide a minimal service guarantee in the face of malicious access. The ANONYMOUS mechanism does not provide a means for the client to supply an optional realm in which the anonymous authentication should take place. This makes the ANONYMOUS mechanism unusable by servers that support multiple realms on a single communication end-point; it cannot supplant the "anonymous@domain" login supported by, for example, some IMAP servers. Philip Guenther From owner-ietf-sasl Thu Feb 20 04:33:52 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KCXq205583 for ietf-sasl-bks; Thu, 20 Feb 2003 04:33:52 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KCXpd05579 for ; Thu, 20 Feb 2003 04:33:51 -0800 (PST) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id h1KCZ8x29392; Thu, 20 Feb 2003 05:35:09 -0700 Message-ID: <3E54CB1B.8FACF46A@messagingdirect.com> Date: Thu, 20 Feb 2003 05:33:31 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Philip Guenther CC: ietf-sasl@imc.org Subject: Re: comments on draft-ietf-sasl-anon-00 References: <200302200807.h1K87JV13985@katroo.Sendmail.COM> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: > The ANONYMOUS mechanism does not provide a means for the client to > supply an optional realm in which the anonymous authentication should > take place. This makes the ANONYMOUS mechanism unusable by servers that > support multiple realms on a single communication end-point; See below. > it cannot supplant the "anonymous@domain" Which conforms to the syntax for "email", isn't it? > login supported by, for example, some IMAP servers. Server is not supposed to verify "email", so anything that looks like "email" just works fine. Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Thu Feb 20 04:41:59 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KCfxS05817 for ietf-sasl-bks; Thu, 20 Feb 2003 04:41:59 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KCfwd05813 for ; Thu, 20 Feb 2003 04:41:58 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09462; Thu, 20 Feb 2003 07:38:09 -0500 (EST) Message-Id: <200302201238.HAA09462@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2831bis-00.txt Date: Thu, 20 Feb 2003 07:38:08 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Using Digest Authentication as a SASL Mechanism Author(s) : P. Leach, C. Newman, A. Melnikov Filename : draft-ietf-sasl-rfc2831bis-00.txt Pages : 35 Date : 2003-2-19 This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2831bis-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2831bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-19142313.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2831bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19142313.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Thu Feb 20 07:20:13 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KFKDC15839 for ietf-sasl-bks; Thu, 20 Feb 2003 07:20:13 -0800 (PST) Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KFKBd15830 for ; Thu, 20 Feb 2003 07:20:12 -0800 (PST) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.7/8.12.7) with ESMTP id h1KFK4Xf023755 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Thu, 20 Feb 2003 16:20:07 +0100 To: ietf-sasl@imc.org Subject: Re: Last call for draft-ietf-sasl-anon-00 X-Payment: hashcash 1.1 0:030220:ietf-sasl@imc.org:414cfd3569157f27 X-Hashcash: 0:030220:ietf-sasl@imc.org:414cfd3569157f27 From: Simon Josefsson Date: Thu, 20 Feb 2003 16:20:04 +0100 In-Reply-To: (Sam Hartman's message of "Wed, 19 Feb 2003 15:13:18 -0500") Message-ID: User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/21.3.50 References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_GNUS_UA version=2.44 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The stringprep profile in section 2 is silent on unassigned code point handling. Perhaps clarify that the list of unassigned code points is empty, if that is indeed what is intended? ,---- RFC 3454 | The list of unassigned code points MUST be given in a profile, and | that list MUST be used by implementations of the profile. `---- From owner-ietf-sasl Thu Feb 20 08:46:41 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KGkfB19262 for ietf-sasl-bks; Thu, 20 Feb 2003 08:46:41 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KGkdd19258 for ; Thu, 20 Feb 2003 08:46:40 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KGkYxH028616; Thu, 20 Feb 2003 16:46:35 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220074940.01a10140@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 08:45:00 -0800 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: Last call for draft-ietf-sasl-anon-00 Cc: ietf-sasl@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 07:20 AM 2/20/2003, Simon Josefsson wrote: >The stringprep profile in section 2 is silent on unassigned code point >handling. Perhaps clarify that the list of unassigned code points is >empty, if that is indeed what is intended? I intended: The list of unassigned code points for this profile is that provided in appendix A of [RFC 3454]. Unassigned code points are not prohibited. Kurt From owner-ietf-sasl Thu Feb 20 10:06:22 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KI6Mc24981 for ietf-sasl-bks; Thu, 20 Feb 2003 10:06:22 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KI6Kd24969 for ; Thu, 20 Feb 2003 10:06:20 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KI69xH029409; Thu, 20 Feb 2003 18:06:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 10:04:34 -0800 To: Philip Guenther From: "Kurt D. Zeilenga" Subject: Unicode/UTF-8 issues (was: comments on draft-ietf-sasl-anon-00) Cc: ietf-sasl@imc.org In-Reply-To: <200302200807.h1K87JV13985@katroo.Sendmail.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:54 PM 2/19/2003, Philip Guenther wrote: >The syntax for UTF-8 characters in the draft permits "non-shortest form" >encodings I'm not exactly sure what you are referring to here. The draft says that the trace information is transferred as string of UTF-8 encoded Unicode characters. A non-shorted form UTF-8 encoding of a Unicode character is invalid per RFC 2247. I believe draft-yergeau-rfc2279bis-04.txt is more clear on this, so I'll change the reference. If, however, you mean that the string of Unicode characters is not normalized using an algorithm which produces the minimum number of code points, yes. This is as intended. >and encodings for characters outside the range of the Unicode >character set. Unassigned code points may be transferred. I will clarify that as I noted in another post. However, I believe the specification is clear that characters "outside the range", e.g. not in the repertoire of characters, are invalid. >Neither may be interpreted by a program conforming to >the Unicode 3.2 specification, which the draft references. Which is exactly why the specification restricts the string to a particular repertoire of characters. Kurt From owner-ietf-sasl Thu Feb 20 10:25:04 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KIP4i27542 for ietf-sasl-bks; Thu, 20 Feb 2003 10:25:04 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KIP2d27535 for ; Thu, 20 Feb 2003 10:25:02 -0800 (PST) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id h1KIQUx00882; Thu, 20 Feb 2003 11:26:30 -0700 Message-ID: <3E551D7A.BFB50CE8@messagingdirect.com> Date: Thu, 20 Feb 2003 11:24:58 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Philip Guenther , ietf-sasl@imc.org Subject: Re: Unicode/UTF-8 issues (was: comments on draft-ietf-sasl-anon-00) References: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" wrote: > At 11:54 PM 2/19/2003, Philip Guenther wrote: > >The syntax for UTF-8 characters in the draft permits "non-shortest form" > >encodings > > I'm not exactly sure what you are referring to here. The > draft says that the trace information is transferred as > string of UTF-8 encoded Unicode characters. A non-shorted > form UTF-8 encoding of a Unicode character is invalid per > RFC 2247. I believe draft-yergeau-rfc2279bis-04.txt is > more clear on this, so I'll change the reference. I believe Philip was referring to ABNF which allows for overlong UTF8 sequences. > If, however, you mean that the string of Unicode characters > is not normalized using an algorithm which produces the > minimum number of code points, yes. This is as intended. Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Thu Feb 20 11:10:43 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KJAhn28968 for ietf-sasl-bks; Thu, 20 Feb 2003 11:10:43 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KJAfd28964 for ; Thu, 20 Feb 2003 11:10:41 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KJAfxH029810; Thu, 20 Feb 2003 19:10:42 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220103201.01a11718@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 11:09:07 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: Unicode/UTF-8 issues (was: comments on draft-ietf-sasl-anon-00) Cc: Philip Guenther , ietf-sasl@imc.org In-Reply-To: <3E551D7A.BFB50CE8@messagingdirect.com> References: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:24 AM 2/20/2003, Alexey Melnikov wrote: >"Kurt D. Zeilenga" wrote: > >> At 11:54 PM 2/19/2003, Philip Guenther wrote: >> >The syntax for UTF-8 characters in the draft permits "non-shortest form" >> >encodings >> >> I'm not exactly sure what you are referring to here. The >> draft says that the trace information is transferred as >> string of UTF-8 encoded Unicode characters. A non-shorted >> form UTF-8 encoding of a Unicode character is invalid per >> RFC 2247. I believe draft-yergeau-rfc2279bis-04.txt is >> more clear on this, so I'll change the reference. > >I believe Philip was referring to ABNF which allows for overlong UTF8 >sequences. I gather that you are saying that ABNF is not precise enough. (please correct me if I wrongly gathered). While I can see that if you ignored all other text and the comments within the ABNF, one could presume that the message, in hex, 0C 30 was valid.... if one actually ignored all the other text and the comments they could also presume that the invalid messages 00 (in hex), foo"bar"@x (in ASCII), and many others were valid. Obviously, the grammar is not intended to be taken out of context. It is provided as a tool for understanding the text of the specification. Kurt From owner-ietf-sasl Thu Feb 20 11:18:54 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KJIsG29250 for ietf-sasl-bks; Thu, 20 Feb 2003 11:18:54 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KJIrd29246 for ; Thu, 20 Feb 2003 11:18:53 -0800 (PST) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id h1KJK8x01507; Thu, 20 Feb 2003 12:20:08 -0700 Message-ID: <3E552A0A.AD59C02B@messagingdirect.com> Date: Thu, 20 Feb 2003 12:18:34 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Philip Guenther , ietf-sasl@imc.org Subject: Re: Unicode/UTF-8 issues (was: comments ondraft-ietf-sasl-anon-00) References: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> <5.2.0.9.0.20030220103201.01a11718@127.0.0.1> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > >I believe Philip was referring to ABNF which allows for overlong UTF8 > >sequences. > > I gather that you are saying that ABNF is not precise enough. Correct. > (please correct me if I wrongly gathered). While I can > see that if you ignored all other text and the comments within > the ABNF, one could presume that the message, in hex, 0C 30 > was valid.... if one actually ignored all the other text > and the comments they could also presume that the invalid > messages 00 (in hex), foo"bar"@x (in ASCII), and many others > were valid. > > Obviously, the grammar is not intended to be taken out of > context. It is provided as a tool for understanding the > text of the specification. I've seen the version of the grammer that deals with overlong sequence. Check draft-yergeau-rfc2279bis-04.txt section 4. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Thu Feb 20 11:31:55 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KJVtm29633 for ietf-sasl-bks; Thu, 20 Feb 2003 11:31:55 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KJVsd29629 for ; Thu, 20 Feb 2003 11:31:54 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KJVtxH030224; Thu, 20 Feb 2003 19:31:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 11:30:21 -0800 To: Philip Guenther From: "Kurt D. Zeilenga" Subject: realms (Was: comments on draft-ietf-sasl-anon-00) Cc: ietf-sasl@imc.org In-Reply-To: <200302200807.h1K87JV13985@katroo.Sendmail.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:54 PM 2/19/2003, Philip Guenther wrote: >The ANONYMOUS mechanism does not provide a means for the client to >supply an optional realm in which the anonymous authentication should >take place. Correct, it doesn't. (The trace information has no semantical value.) >This makes the ANONYMOUS mechanism unusable by servers that >support multiple realms on a single communication end-point; it cannot >supplant the "anonymous@domain" login supported by, for example, some >IMAP servers. Maybe so. Are you asking for the WG to consider adding realm support to ANONYMOUS mechanism? Or asking the WG to consider clarifications to the ANONYMOUS mechanism that it is not applicable in scenarios allowing different anonymous associations to be established? Kurt From owner-ietf-sasl Thu Feb 20 11:56:46 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KJukx01064 for ietf-sasl-bks; Thu, 20 Feb 2003 11:56:46 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KJuid01060 for ; Thu, 20 Feb 2003 11:56:44 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KJujxH030510; Thu, 20 Feb 2003 19:56:46 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220115255.026602a0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 11:55:11 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: Unicode/UTF-8 issues (was: comments ondraft-ietf-sasl-anon-00) Cc: Philip Guenther , ietf-sasl@imc.org In-Reply-To: <3E552A0A.AD59C02B@messagingdirect.com> References: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> <5.2.0.9.0.20030220103201.01a11718@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Okay, how about I replace the grammar and the paragraph before it as follows: A formal grammar for the client message using Augmented BNF [ABNF] is provide below as a tool for understanding this technical specification. message = [ email / token ] ;; MUST be prepared in accordance with Section 2 UTF1 = %x00-3F / %x41-7F ;; less '@' (U+0040) UTF2 = %xC2-DF UTF0 UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / %xF4 %x80-8F 2(UTF0) UTF0 = %x80-BF TCHAR = UTF1 / UTF2 / UTF3 / UTF3 / UTF4 ;; any UTF-8 encoded Unicode character ;; except '@' (U+0040) email = addr-spec ;; as defined in [IMAIL], except with no free ;; insertion of linear-white-space, and the ;; local-part MUST either be entirely enclosed in ;; quotes or entirely unquoted token = 1*255TCHAR and add an appropriate acknowledgement. Kurt From owner-ietf-sasl Thu Feb 20 12:10:08 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKA8j01474 for ietf-sasl-bks; Thu, 20 Feb 2003 12:10:08 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKA6d01470 for ; Thu, 20 Feb 2003 12:10:06 -0800 (PST) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id h1KKBUx02009; Thu, 20 Feb 2003 13:11:30 -0700 Message-ID: <3E553615.C2717C86@messagingdirect.com> Date: Thu, 20 Feb 2003 13:09:57 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Philip Guenther , ietf-sasl@imc.org Subject: Re: Unicode/UTF-8 issues (was: commentsondraft-ietf-sasl-anon-00) References: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> <5.2.0.9.0.20030220103201.01a11718@127.0.0.1> <5.2.0.9.0.20030220115255.026602a0@127.0.0.1> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" wrote: > Okay, how about I replace the grammar and the paragraph before > it as follows: This mostly works, see below. > A formal grammar for the client message using Augmented BNF [ABNF] > is provide below as a tool for understanding this technical > specification. > > message = [ email / token ] > ;; MUST be prepared in accordance with Section 2 > > UTF1 = %x00-3F / %x41-7F ;; less '@' (U+0040) > UTF2 = %xC2-DF UTF0 > UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / > %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) > UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / > %xF4 %x80-8F 2(UTF0) > UTF0 = %x80-BF > > TCHAR = UTF1 / UTF2 / UTF3 / UTF3 / UTF4 > ;; any UTF-8 encoded Unicode character > ;; except '@' (U+0040) Hmm, this suggests a typo in draft-yergeau-rfc2279bis-04.txt (UTF3 is shown twice). Also note, that this doesn't have UTF5 & UTF6 that you currently have: UTF5 = %xF8-FB 4(UTF0) UTF6 = %xFC-FD 5(UTF0) (but they have to be cleaned up to prevent overlong sequences). > email = addr-spec > ;; as defined in [IMAIL], except with no free > ;; insertion of linear-white-space, and the > ;; local-part MUST either be entirely enclosed in > ;; quotes or entirely unquoted > > token = 1*255TCHAR > > and add an appropriate acknowledgement. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Thu Feb 20 12:08:36 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KK8ah01404 for ietf-sasl-bks; Thu, 20 Feb 2003 12:08:36 -0800 (PST) Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KK8Zd01400 for ; Thu, 20 Feb 2003 12:08:35 -0800 (PST) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h1KK8aG24293; Thu, 20 Feb 2003 12:08:36 -0800 (PST) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.6/8.11.6) with ESMTP id h1KK9rV11903; Thu, 20 Feb 2003 12:09:53 -0800 (PST) Message-Id: <200302202009.h1KK9rV11903@katroo.Sendmail.COM> To: "Kurt D. Zeilenga" Cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: Unicode/UTF-8 issues (was: comments on draft-ietf-sasl-anon-00) In-reply-to: <5.2.0.9.0.20030220103201.01a11718@127.0.0.1> References: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> <5.2.0.9.0.20030220103201.01a11718@127.0.0.1> Date: Thu, 20 Feb 2003 11:56:34 -0800 From: Philip Guenther Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: ... >I gather that you are saying that ABNF is not precise enough. >(please correct me if I wrongly gathered). While I can >see that if you ignored all other text and the comments within >the ABNF, one could presume that the message, in hex, 0C 30 >was valid.... if one actually ignored all the other text >and the comments they could also presume that the invalid >messages 00 (in hex), foo"bar"@x (in ASCII), and many others >were valid. No, the latter is not valid by the grammar. My dislike for the current formulation is two-fold: TCHAR, as defined, isn't actually "any UTF-8 encoded Unicode character except '@' (U+0040)" as described in the comment. The UTF5 and UTF6 definitions do not match any legal UTF-8 character and the UTF3 and UTF4 definitions match illegal UTF-8 characters. I would prefer to find all the restrictions on what characters are legal in a token in a single location. The grammar could simply define TCHAR as a UTF-8 encoded character (perhaps using the productions in the draft Alexey mentioned) while the stringprep profile could handle all the restrictions on content at the level of Unicode characters. Yes, this makes the grammar ambiguous, but even rfc2822, the first 'target' for ABNF, has an amibiguous grammar that is only resolved by semantic restrictions in the general text. >Obviously, the grammar is not intended to be taken out of >context. It is provided as a tool for understanding the >text of the specification. As always, clarity and correctness are the goals. IMHO, defining a non-terminal that's neither a superset nor a subset of UTF-8, with additional restrictions elsewhere, makes it more difficult to understand. Philip Guenther From owner-ietf-sasl Thu Feb 20 12:25:11 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKPBK02795 for ietf-sasl-bks; Thu, 20 Feb 2003 12:25:11 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKP9d02788 for ; Thu, 20 Feb 2003 12:25:09 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KKPBxH030925; Thu, 20 Feb 2003 20:25:11 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220115540.026fff98@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 12:23:36 -0800 To: Philip Guenther From: "Kurt D. Zeilenga" Subject: security considerations (was: comments on draft-ietf-sasl-anon-00) Cc: ietf-sasl@imc.org In-Reply-To: <200302200807.h1K87JV13985@katroo.Sendmail.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:54 PM 2/19/2003, Philip Guenther wrote: >Paragraph 5 of section 4 (security consideration), suggests the use of >an idle timeout on servers that place a limit on the number of >concurrent anonymous users in order to combat a denial-of-service >attack. As keeping a connection from being considered idle will >generally require simply sending a request (possibly even a malformed >request), it's unlikely that an idle timeout will actually prevent an >intentional DOS attack from succeeding. A hard timeout on connection >duration, network access limitations, or (where appropriate) a limit on >the number of requests permitted on an anonymous connection may be >required to provide a minimal service guarantee in the face of malicious >access. I'm thinking the problem starts in paragraph 4 with the suggestion that servers should restrict the numbers of anonymous users. How about replacing both paragraph 4 and 5 with: If the anonymous user can run many expensive operations (e.g., an IMAP SEARCH BODY command), this could enable a denial of service attack. Servers are encouraged to reduce the priority of anonymous users or limit their resource usage. While servers may impose a limit on the number of anonymous users, it is noted that such a limit enables denial of service attacks and should be used with caution. From owner-ietf-sasl Thu Feb 20 12:34:27 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKYRm03125 for ietf-sasl-bks; Thu, 20 Feb 2003 12:34:27 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKYQd03120 for ; Thu, 20 Feb 2003 12:34:26 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KKYRxH031004; Thu, 20 Feb 2003 20:34:27 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220123001.026faf68@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 12:32:52 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: Unicode/UTF-8 issues (was: commentsondraft-ietf-sasl-anon-00) Cc: Philip Guenther , ietf-sasl@imc.org In-Reply-To: <3E553615.C2717C86@messagingdirect.com> References: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> <5.2.0.9.0.20030220103201.01a11718@127.0.0.1> <5.2.0.9.0.20030220115255.026602a0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:09 PM 2/20/2003, Alexey Melnikov wrote: >"Kurt D. Zeilenga" wrote: > >> Okay, how about I replace the grammar and the paragraph before >> it as follows: > >This mostly works, see below. > >> A formal grammar for the client message using Augmented BNF [ABNF] >> is provide below as a tool for understanding this technical >> specification. >> >> message = [ email / token ] >> ;; MUST be prepared in accordance with Section 2 >> >> UTF1 = %x00-3F / %x41-7F ;; less '@' (U+0040) >> UTF2 = %xC2-DF UTF0 >> UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / >> %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) >> UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / >> %xF4 %x80-8F 2(UTF0) >> UTF0 = %x80-BF >> >> TCHAR = UTF1 / UTF2 / UTF3 / UTF3 / UTF4 >> ;; any UTF-8 encoded Unicode character >> ;; except '@' (U+0040) > >Hmm, this suggests a typo in draft-yergeau-rfc2279bis-04.txt (UTF3 is >shown twice). Or an error on my part. UTF3 should only be listed once here. >Also note, that this doesn't have UTF5 & UTF6 that you currently have: > > UTF5 = %xF8-FB 4(UTF0) > UTF6 = %xFC-FD 5(UTF0) > >(but they have to be cleaned up to prevent overlong sequences). Yes. There are a couple of 4 v 6 octet cleanups to be made as well. From owner-ietf-sasl Thu Feb 20 12:37:18 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKbIl03209 for ietf-sasl-bks; Thu, 20 Feb 2003 12:37:18 -0800 (PST) Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKbHd03204 for ; Thu, 20 Feb 2003 12:37:17 -0800 (PST) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h1KKbIG27039; Thu, 20 Feb 2003 12:37:18 -0800 (PST) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.6/8.11.6) with ESMTP id h1KKcZV15308; Thu, 20 Feb 2003 12:38:35 -0800 (PST) Message-Id: <200302202038.h1KKcZV15308@katroo.Sendmail.COM> To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) In-reply-to: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> References: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> Date: Thu, 20 Feb 2003 12:25:16 -0800 From: Philip Guenther Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: >At 11:54 PM 2/19/2003, Philip Guenther wrote: ... >>This makes the ANONYMOUS mechanism unusable by servers that >>support multiple realms on a single communication end-point; it cannot >>supplant the "anonymous@domain" login supported by, for example, some >>IMAP servers. > >Maybe so. > >Are you asking for the WG to consider adding realm support >to ANONYMOUS mechanism? Or asking the WG to consider >clarifications to the ANONYMOUS mechanism that it is not >applicable in scenarios allowing different anonymous >associations to be established? The latter, not the former. While a mechanism that supports multiple anonymous identities may have its place in the SASL 'cookbook', I don't currently have a clear idea of what would be generally useful in that direction to suggest changing the current ANONYMOUS mechanism at this time. Philip Guenther From owner-ietf-sasl Thu Feb 20 12:38:43 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKchc03276 for ietf-sasl-bks; Thu, 20 Feb 2003 12:38:43 -0800 (PST) Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKcgd03272 for ; Thu, 20 Feb 2003 12:38:42 -0800 (PST) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h1KKchG27428; Thu, 20 Feb 2003 12:38:43 -0800 (PST) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.6/8.11.6) with ESMTP id h1KKe0V15449; Thu, 20 Feb 2003 12:40:00 -0800 (PST) Message-Id: <200302202040.h1KKe0V15449@katroo.Sendmail.COM> To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org From: Philip Guenther Subject: Re: security considerations (was: comments on draft-ietf-sasl-anon-00) In-reply-to: <5.2.0.9.0.20030220115540.026fff98@127.0.0.1> References: <5.2.0.9.0.20030220115540.026fff98@127.0.0.1> Date: Thu, 20 Feb 2003 12:26:41 -0800 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: ... >I'm thinking the problem starts in paragraph 4 with the >suggestion that servers should restrict the numbers of >anonymous users. How about replacing both paragraph 4 and >5 with: Looks good to me. Philip Guenther From owner-ietf-sasl Thu Feb 20 12:39:29 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKdTm03297 for ietf-sasl-bks; Thu, 20 Feb 2003 12:39:29 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKdRd03293 for ; Thu, 20 Feb 2003 12:39:27 -0800 (PST) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id h1KKemx02427; Thu, 20 Feb 2003 13:40:49 -0700 Message-ID: <3E553CF3.A4913260@messagingdirect.com> Date: Thu, 20 Feb 2003 13:39:15 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Philip Guenther , ietf-sasl@imc.org Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) References: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" wrote: > At 11:54 PM 2/19/2003, Philip Guenther wrote: > >The ANONYMOUS mechanism does not provide a means for the client to > >supply an optional realm in which the anonymous authentication should > >take place. > > Correct, it doesn't. (The trace information has no semantical > value.) > > >This makes the ANONYMOUS mechanism unusable by servers that > >support multiple realms on a single communication end-point; it cannot > >supplant the "anonymous@domain" login supported by, for example, some > >IMAP servers. > > Maybe so. > > Are you asking for the WG to consider adding realm support > to ANONYMOUS mechanism? Just to clarify: the solution can be as simple as saying that domain part of an "email" can be parsed by the server in order to figure out realm. > Or asking the WG to consider > clarifications to the ANONYMOUS mechanism that it is not > applicable in scenarios allowing different anonymous > associations to be established? Cheers, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Thu Feb 20 12:46:43 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKkhj03560 for ietf-sasl-bks; Thu, 20 Feb 2003 12:46:43 -0800 (PST) Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKkgd03556 for ; Thu, 20 Feb 2003 12:46:42 -0800 (PST) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h1KKkiG28022; Thu, 20 Feb 2003 12:46:44 -0800 (PST) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.6/8.11.6) with ESMTP id h1KKm0V16300; Thu, 20 Feb 2003 12:48:01 -0800 (PST) Message-Id: <200302202048.h1KKm0V16300@katroo.Sendmail.COM> To: Alexey Melnikov Cc: ietf-sasl@imc.org From: Philip Guenther Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) In-reply-to: <3E553CF3.A4913260@messagingdirect.com> References: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> <3E553CF3.A4913260@messagingdirect.com> Date: Thu, 20 Feb 2003 12:34:41 -0800 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >"Kurt D. Zeilenga" wrote: >> At 11:54 PM 2/19/2003, Philip Guenther wrote: >> >The ANONYMOUS mechanism does not provide a means for the client to >> >supply an optional realm in which the anonymous authentication should >> >take place. ... >> Are you asking for the WG to consider adding realm support >> to ANONYMOUS mechanism? > >Just to clarify: the solution can be as simple as saying that domain part >of an "email" can be parsed by the server in order to figure out realm. I don't think an rfc should suggest automated parsing of trace information. Such a practice would arguably make the non-address form a second-class citizen and possibly lead to the use of placeholder addressees when a general text string would have been more appropriate. Philip Guenther From owner-ietf-sasl Thu Feb 20 12:53:59 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKrxe04718 for ietf-sasl-bks; Thu, 20 Feb 2003 12:53:59 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKrwd04710 for ; Thu, 20 Feb 2003 12:53:58 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KKs0xH031382; Thu, 20 Feb 2003 20:54:00 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220125156.01a3ecb0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 12:52:24 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) Cc: Philip Guenther , ietf-sasl@imc.org In-Reply-To: <3E553CF3.A4913260@messagingdirect.com> References: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:39 PM 2/20/2003, Alexey Melnikov wrote: >Just to clarify: the solution can be as simple as saying that domain part >of an "email" can be parsed by the server in order to figure out realm. I would rather clarify that the trace information has no semantical value. Kurt From owner-ietf-sasl Thu Feb 20 12:51:26 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKpQI04259 for ietf-sasl-bks; Thu, 20 Feb 2003 12:51:26 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKpPd04252 for ; Thu, 20 Feb 2003 12:51:25 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KKpRxH031274; Thu, 20 Feb 2003 20:51:27 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220124111.027081b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 12:49:52 -0800 To: Philip Guenther From: "Kurt D. Zeilenga" Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) Cc: ietf-sasl@imc.org In-Reply-To: <200302202038.h1KKcZV15308@katroo.Sendmail.COM> References: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> <5.2.0.9.0.20030220111223.02503718@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:25 PM 2/20/2003, Philip Guenther wrote: >>Are you asking for the WG to consider adding realm support >>to ANONYMOUS mechanism? Or asking the WG to consider >>clarifications to the ANONYMOUS mechanism that it is not >>applicable in scenarios allowing different anonymous >>associations to be established? > >The latter, not the former. Okay. I suggest you (or another proponent of the clarification) offer text for the WG to consider. Kurt From owner-ietf-sasl Fri Feb 21 13:16:19 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1LLGJT24954 for ietf-sasl-bks; Fri, 21 Feb 2003 13:16:19 -0800 (PST) Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1LLGId24948 for ; Fri, 21 Feb 2003 13:16:18 -0800 (PST) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h1LLGJG10247; Fri, 21 Feb 2003 13:16:19 -0800 (PST) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.6/8.11.6) with ESMTP id h1LLHaV17559; Fri, 21 Feb 2003 13:17:37 -0800 (PST) Message-Id: <200302212117.h1LLHaV17559@katroo.Sendmail.COM> To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) In-reply-to: <5.2.0.9.0.20030220124111.027081b8@127.0.0.1> References: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> <5.2.0.9.0.20030220111223.02503718@127.0.0.1> <5.2.0.9.0.20030220124111.027081b8@127.0.0.1> Date: Fri, 21 Feb 2003 13:04:07 -0800 From: Philip Guenther Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: >At 12:25 PM 2/20/2003, Philip Guenther wrote: >>>Are you asking for the WG to consider adding realm support >>>to ANONYMOUS mechanism? Or asking the WG to consider >>>clarifications to the ANONYMOUS mechanism that it is not >>>applicable in scenarios allowing different anonymous >>>associations to be established? >> >>The latter, not the former. > >Okay. I suggest you (or another proponent of the clarification) >offer text for the WG to consider. How about the following sentence for addition to section 1, perhaps right after the 'no security layer' paragraph? "The ANONYMOUS mechanism is not applicable to servers that support multiple anonymous identities and that do not have enough information from before the SASL exchange (for example, from previous protocol exchanges or the connection addresses) to determine which identity to use." Philip Guenther From owner-ietf-sasl Fri Feb 21 13:51:28 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1LLpSe26561 for ietf-sasl-bks; Fri, 21 Feb 2003 13:51:28 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1LLpQd26557 for ; Fri, 21 Feb 2003 13:51:26 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1LLpSxH046054; Fri, 21 Feb 2003 21:51:28 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030221133147.0278b1b0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 21 Feb 2003 13:49:52 -0800 To: Philip Guenther From: "Kurt D. Zeilenga" Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) Cc: ietf-sasl@imc.org In-Reply-To: <200302212117.h1LLHaV17559@katroo.Sendmail.COM> References: <5.2.0.9.0.20030220124111.027081b8@127.0.0.1> <5.2.0.9.0.20030220111223.02503718@127.0.0.1> <5.2.0.9.0.20030220111223.02503718@127.0.0.1> <5.2.0.9.0.20030220124111.027081b8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 01:04 PM 2/21/2003, Philip Guenther wrote: >How about the following sentence for addition to section 1, perhaps >right after the 'no security layer' paragraph? > >"The ANONYMOUS mechanism is not applicable to servers that support > multiple anonymous identities and that do not have enough information > from before the SASL exchange (for example, from previous protocol > exchanges or the connection addresses) to determine which identity to > use." A few comments. I think "anonymous identity" is an oxymoron. And, of course, the ANONYMOUS mechanism is not intended to determine any identity. One possible alternative wording, which would at avoid these issues, would be: The ANONYMOUS mechanism is not applicable where application-level protocols and/or their implementations offer more than one kind/type/level of anonymous associations between the client and the server as the mechanism provides no facility to indicate the kind/type/level of associate desired. No semantics should be associated with the trace information. Kurt From owner-ietf-sasl Fri Feb 21 19:24:30 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1M3OUI05125 for ietf-sasl-bks; Fri, 21 Feb 2003 19:24:30 -0800 (PST) Received: from konishi-polis.mit.edu (STRATTON-FOUR-THIRTY-FOUR.MIT.EDU [18.187.6.179]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1M3OTd05121 for ; Fri, 21 Feb 2003 19:24:30 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 9E3BD151F11; Fri, 21 Feb 2003 22:24:30 -0500 (EST) To: "Kurt D. Zeilenga" Cc: Alexey Melnikov , Philip Guenther , ietf-sasl@imc.org Subject: Re: realms References: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> <5.2.0.9.0.20030220125156.01a3ecb0@127.0.0.1> From: Sam Hartman Date: Fri, 21 Feb 2003 22:24:30 -0500 In-Reply-To: <5.2.0.9.0.20030220125156.01a3ecb0@127.0.0.1> ("Kurt D. Zeilenga"'s message of "Thu, 20 Feb 2003 12:52:24 -0800") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> At 12:39 PM 2/20/2003, Alexey Melnikov wrote: >> Just to clarify: the solution can be as simple as saying that domain part >> of an "email" can be parsed by the server in order to figure out realm. Kurt> I would rather clarify that the trace information has Kurt> no semantical value. Kurt> Kurt I tend to agree that if a clarification is made it should be in the direction of no semantic value for the trace component. This is just another rehash of the authorization name vs authentication name problem all over again. There is exactly one anonymous authentication name in the universe. It may have trace information associated with it but anonymous logins are all the same. The anonymous identity may be authorized for several different authorization identities--these identities may even correspond to different realms. Our current mechanism does not provide a way to express this authorization identity and expanding the mechanism now is probably a bad idea and possible out of scope. It may be appropriate for some future anonymous mechanism to support authorization identity if that is useful. From owner-ietf-sasl Thu Feb 27 04:49:31 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RCnV704093 for ietf-sasl-bks; Thu, 27 Feb 2003 04:49:31 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RCnTY04089 for ; Thu, 27 Feb 2003 04:49:30 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27915; Thu, 27 Feb 2003 07:45:33 -0500 (EST) Message-Id: <200302271245.HAA27915@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-saslprep-00.txt Date: Thu, 27 Feb 2003 07:45:32 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : SASLprep: Stringprep profile for user names and passwords Author(s) : K. Zeilenga Filename : draft-ietf-sasl-saslprep-00.txt Pages : 5 Date : 2003-2-26 This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the 'SASLprep' 'stringprep' profile to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging user names and/or passwords. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-saslprep-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-saslprep-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-26160958.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-saslprep-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-saslprep-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-26160958.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Thu Feb 27 07:57:31 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RFvV015731 for ietf-sasl-bks; Thu, 27 Feb 2003 07:57:31 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RFvTY15723 for ; Thu, 27 Feb 2003 07:57:30 -0800 (PST) Received: from fermi (h24-86-178-58.ed.shawcable.net [24.86.178.58]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id h1RFwwe17103 for ; Thu, 27 Feb 2003 08:58:59 -0700 From: Steve Hole Date: Thu, 27 Feb 2003 08:57:27 -0700 To: ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-ietf-sasl-saslprep-00.txt In-Reply-To: <200302271245.HAA27915@ietf.org> References: <200302271245.HAA27915@ietf.org> Message-ID: X-Mailer: Execmail for Win32 5.1.1 Build (10) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 27 Feb 2003 07:45:32 -0500 Internet-Drafts@ietf.org wrote: > This document describes how to prepare Unicode strings representing > user names and passwords for comparison. The document defines the > 'SASLprep' 'stringprep' profile to be used for both user names and > passwords. This profile is intended to be used by Simple > Authentication and Security Layer (SASL) mechanisms (such as PLAIN, > CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging user > names and/or passwords. It is entirely possible that I have missed some conversation that answers this question ... if so I apologize. Why is this necessary. Those mechanisms that are recommended for use (CRAM-MD5 is effectively deprecated in favour of Digest) support use of UTF8 encoded strings. Why we would need to do anything else for exact comparison purposes? Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 From owner-ietf-sasl Thu Feb 27 11:04:21 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RJ4Lr00777 for ietf-sasl-bks; Thu, 27 Feb 2003 11:04:21 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RJ4JY00772 for ; Thu, 27 Feb 2003 11:04:19 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1RJ4K8q021982; Thu, 27 Feb 2003 19:04:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030227105153.01a04258@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 27 Feb 2003 11:02:39 -0800 To: Steve Hole From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-saslprep-00.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200302271245.HAA27915@ietf.org> <200302271245.HAA27915@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 07:57 AM 2/27/2003, Steve Hole wrote: >On Thu, 27 Feb 2003 07:45:32 -0500 Internet-Drafts@ietf.org wrote: > > >> This document describes how to prepare Unicode strings representing >> user names and passwords for comparison. The document defines the >> 'SASLprep' 'stringprep' profile to be used for both user names and >> passwords. This profile is intended to be used by Simple >> Authentication and Security Layer (SASL) mechanisms (such as PLAIN, >> CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging user >> names and/or passwords. > >It is entirely possible that I have missed some conversation that answers >this question ... if so I apologize. Why is this necessary. Those >mechanisms that are recommended for use (CRAM-MD5 is effectively >deprecated in favour of Digest) support use of UTF8 encoded strings. Why >we would need to do anything else for exact comparison purposes? To ensure that two different, but canonically equivalent, Unicode strings are treated as being the same. Kurt From owner-ietf-sasl Fri Feb 28 04:29:46 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SCTkb09541 for ietf-sasl-bks; Fri, 28 Feb 2003 04:29:46 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SCTjY09537 for ; Fri, 28 Feb 2003 04:29:45 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22735; Fri, 28 Feb 2003 07:25:48 -0500 (EST) Message-Id: <200302281225.HAA22735@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-hansen-sasl-pki-00.txt Date: Fri, 28 Feb 2003 07:25:47 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The PKI SASL Mechanism Author(s) : T. Hansen Filename : draft-hansen-sasl-pki-00.txt Pages : 6 Date : 2003-2-27 This document defines a user/password Simple Authentication and Security Layer(SASL) mechanism called the PKI mechanism. The PKI mechanism is intended to be used in situations where (1) passwords must be encrypted, (2) the password must be recoverable, and (3) using TLS in combination with a SASL mechanism such as PLAIN is inappropriate. NOTE: This document is a straw proposal to see what interest there is in having a SASL mechanism such as this. See the first section below for more information on why this mechanism is needed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hansen-sasl-pki-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hansen-sasl-pki-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hansen-sasl-pki-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-27132918.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hansen-sasl-pki-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hansen-sasl-pki-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-27132918.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Fri Feb 28 09:00:22 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SH0MH24332 for ietf-sasl-bks; Fri, 28 Feb 2003 09:00:22 -0800 (PST) Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SH0LY24326 for ; Fri, 28 Feb 2003 09:00:21 -0800 (PST) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.7/8.12.7) with ESMTP id h1SH0G0r004368; Fri, 28 Feb 2003 12:00:16 -0500 Message-ID: <3E5F962B.E5CADDDA@oceana.com> Date: Fri, 28 Feb 2003 12:02:35 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: tony@att.com CC: SASL mailing list Subject: draft-hansen-sasl-pki-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony, I assume that this is in response to discussions/complaints on ietf-nntp? Can you compare/contrast what you have in mind to Newman's PASSDSS? http://www.alternic.org/drafts/drafts-n-o/draft-newman-sasl-passdss-01.txt -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Fri Feb 28 10:08:46 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SI8kE27753 for ietf-sasl-bks; Fri, 28 Feb 2003 10:08:46 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SI8iY27740 for ; Fri, 28 Feb 2003 10:08:44 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1SI8e8q033102; Fri, 28 Feb 2003 18:08:41 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Feb 2003 10:06:54 -0800 To: tony@att.com From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt Cc: ietf-sasl@imc.org In-Reply-To: <200302281225.HAA22735@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony, What's the advantage of this approach over using TLS+SASL/PLAIN and then just closing TLS gracefully so that remainder of the session is in the clear? Kurt At 04:25 AM 2/28/2003, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : The PKI SASL Mechanism > Author(s) : T. Hansen > Filename : draft-hansen-sasl-pki-00.txt > Pages : 6 > Date : 2003-2-27 > >This document defines a user/password Simple Authentication and >Security Layer(SASL) mechanism called the PKI mechanism. The PKI >mechanism is intended to be used in situations where (1) passwords must >be encrypted, (2) the password must be recoverable, and (3) using TLS in >combination with a SASL mechanism such as PLAIN is inappropriate. >NOTE: This document is a straw proposal to see what interest there >is in having a SASL mechanism such as this. See the first section below >for more information on why this mechanism is needed. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-hansen-sasl-pki-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-hansen-sasl-pki-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-hansen-sasl-pki-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2003-2-27132918.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-hansen-sasl-pki-00.txt > > From owner-ietf-sasl Fri Feb 28 11:01:09 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SJ19701377 for ietf-sasl-bks; Fri, 28 Feb 2003 11:01:09 -0800 (PST) Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SJ18Y01373 for ; Fri, 28 Feb 2003 11:01:08 -0800 (PST) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.7/8.12.7) with ESMTP id h1SJ130r006557; Fri, 28 Feb 2003 14:01:03 -0500 Message-ID: <3E5FB27B.9964C86A@oceana.com> Date: Fri, 28 Feb 2003 14:03:23 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: tony@att.com, ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt References: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" wrote: > > Tony, > > What's the advantage of this approach over using TLS+SASL/PLAIN > and then just closing TLS gracefully so that remainder of the > session is in the clear? Hmm. I always thought that it was implied that TLS would be active until the end of the session. Can this be done gracefully so that both client and server is happy (are there any existing implementations that wouldn't freak)? Who can/should initiate the shutdown? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Fri Feb 28 11:02:52 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SJ2qC01430 for ietf-sasl-bks; Fri, 28 Feb 2003 11:02:52 -0800 (PST) Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SJ2pY01426 for ; Fri, 28 Feb 2003 11:02:51 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp5.andrew.cmu.edu (8.12.7.Beta1/8.12.3.Beta2) with ESMTP id h1SJ2pRI019902; Fri, 28 Feb 2003 14:02:51 -0500 Date: Fri, 28 Feb 2003 14:02:51 -0500 Message-Id: <200302281902.h1SJ2pRI019902@smtp5.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: tony@att.com, "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org In-reply-to: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt References: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Fri, 28 Feb 2003 10:06:54 -0800 From: "Kurt D. Zeilenga" What's the advantage of this approach over using TLS+SASL/PLAIN and then just closing TLS gracefully so that remainder of the session is in the clear? You don't close TLS; you can renegotiate to the NULL cipher. Larry From owner-ietf-sasl Fri Feb 28 11:17:17 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SJHHm03396 for ietf-sasl-bks; Fri, 28 Feb 2003 11:17:17 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SJHFY03389 for ; Fri, 28 Feb 2003 11:17:15 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1SJHF8q033908; Fri, 28 Feb 2003 19:17:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030228110305.01a2ec18@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Feb 2003 11:15:33 -0800 To: Ken Murchison From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt Cc: tony@att.com, ietf-sasl@imc.org In-Reply-To: <3E5FB27B.9964C86A@oceana.com> References: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:03 AM 2/28/2003, Ken Murchison wrote: >"Kurt D. Zeilenga" wrote: >> What's the advantage of this approach over using TLS+SASL/PLAIN >> and then just closing TLS gracefully so that remainder of the >> session is in the clear? > >Hmm. I always thought that it was implied that TLS would be active >until the end of the session. Well, that's maybe how some application-layer protocols specify how TLS is to be used, but TLS does support closure (and subsequent restart). For an example of how one application layer protocol allows TLS closure (and restart), see Section 4.1 of RFC 2830 (LDAPv3 Start TLS). >Can this be done gracefully so that both >client and server is happy (are there any existing implementations that >wouldn't freak)? Yes. But there application-layer issues (such as how to handle outstanding operations, etc.) which need to be address in the technical specification detailing use of TLS in that application-layer protocol. >Who can/should initiate the shutdown? Either TLS peer can issue a closure alert. Kurt From owner-ietf-sasl Fri Feb 28 11:24:10 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SJOAe04545 for ietf-sasl-bks; Fri, 28 Feb 2003 11:24:10 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SJO9Y04539 for ; Fri, 28 Feb 2003 11:24:09 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1SJO78q033959; Fri, 28 Feb 2003 19:24:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030228111727.02a2be70@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Feb 2003 11:22:25 -0800 To: Lawrence Greenfield From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt Cc: tony@att.com, ietf-sasl@imc.org In-Reply-To: <200302281902.h1SJ2pRI019902@smtp5.andrew.cmu.edu> References: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:02 AM 2/28/2003, Lawrence Greenfield wrote: > Date: Fri, 28 Feb 2003 10:06:54 -0800 > From: "Kurt D. Zeilenga" > > What's the advantage of this approach over using TLS+SASL/PLAIN > and then just closing TLS gracefully so that remainder of the > session is in the clear? > >You don't close TLS; you can renegotiate to the NULL cipher. Application-level protocols may permit use the stream after TLS closure. See RFC 2246, Section 7.2.1. LDAPv3 is an example, RFC 2830, of an application-level protocol which explicitly permits such use. Kurt From owner-ietf-sasl Fri Feb 28 11:46:39 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SJkdv06560 for ietf-sasl-bks; Fri, 28 Feb 2003 11:46:39 -0800 (PST) Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SJkbY06555 for ; Fri, 28 Feb 2003 11:46:37 -0800 (PST) Received: from maillennium.att.com ([135.25.114.99]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h1SJkSWJ005692 for ; Fri, 28 Feb 2003 13:46:28 -0600 (CST) Received: from att.com ([135.210.10.156]) by maillennium.att.com (mailgw1) with SMTP id <20030228194547gw100kselme> (Authid: tony); Fri, 28 Feb 2003 19:45:47 +0000 Message-ID: <3E5FBC71.9070700@att.com> Date: Fri, 28 Feb 2003 14:45:53 -0500 From: Tony Hansen User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt References: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> In-Reply-To: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All the application protocols have a way of saying "I want to turn TLS on", but none of the application protocols have a way to say "now I want to turn TLS off". I even think that the "start TLS" specs in most application protocols explicitly say that you CANNOT switch it back off. Within the TLS layer, you can negotiate switching to a null cipher. But there is no way to mandate that up at the application protocol level. Plus I think there're still other overheads of TLS that don't go away. Tony Hansen tony@att.com Kurt D. Zeilenga wrote: > What's the advantage of this approach over using TLS+SASL/PLAIN > and then just closing TLS gracefully so that remainder of the > session is in the clear? From owner-ietf-sasl Fri Feb 28 12:41:32 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SKfWu08417 for ietf-sasl-bks; Fri, 28 Feb 2003 12:41:32 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SKfVY08413 for ; Fri, 28 Feb 2003 12:41:31 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1SKfV8q034488; Fri, 28 Feb 2003 20:41:31 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030228121133.01a0f518@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Feb 2003 12:39:49 -0800 To: Tony Hansen From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt Cc: ietf-sasl@imc.org In-Reply-To: <3E5FBC71.9070700@att.com> References: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:45 AM 2/28/2003, Tony Hansen wrote: >All the application protocols have a way of saying "I want to turn TLS on", >but none of the application protocols have a way to say "now I want to turn TLS off". TLS closure alert says "I want to turn TLS off". Every application protocol which profiles TLS should state what happens when this is said. >I even think that the "start TLS" specs in most application protocols explicitly say that you CANNOT switch it back off. I suspect most application protocol specifications are mute on what to do upon TLS closure. Anyways, it seems what you are saying is, you need a new mechanism because some application protocol profiles of TLS don't allow messages to be exchanged post TLS closure. I would add, and where they do allow such, not all implementations support it. I suggest briefly discuss in your draft why a TLS+SASL/PLAIN+closure approach is not well suited to your needs. >Within the TLS layer, you can negotiate switching to a null cipher. But there is no way to mandate that up at the application protocol level. Most TLS implementations I know provide applications with adequate control over which cipher suites may be used, as well as which cipher suite is in use, so that they may ensure they can enforce applicable security policies. >Plus I think there're still other overheads of TLS that don't go away. I would think that a good TLS implementation would have minimal overhead when a null cipher suite was in use. From owner-ietf-sasl Tue Feb 11 03:50:11 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1BBoBT13831 for ietf-sasl-bks; Tue, 11 Feb 2003 03:50:11 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BBoAd13827 for ; Tue, 11 Feb 2003 03:50:10 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28775; Tue, 11 Feb 2003 06:46:27 -0500 (EST) Message-Id: <200302111146.GAA28775@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-plain-00.txt Date: Tue, 11 Feb 2003 06:46:27 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The Plain SASL Mechanism Author(s) : K. Zeilenga Filename : draft-ietf-sasl-plain-00.txt Pages : 8 Date : 2003-2-10 This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols which lack a simple password authentication command. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-plain-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-plain-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-plain-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-10135953.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-plain-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-plain-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-10135953.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Wed Feb 19 12:13:18 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1JKDIT07214 for ietf-sasl-bks; Wed, 19 Feb 2003 12:13:18 -0800 (PST) Received: from konishi-polis.mit.edu (STRATTON-FOUR-THIRTY-FOUR.MIT.EDU [18.187.6.179]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1JKDHd07209 for ; Wed, 19 Feb 2003 12:13:17 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id B64EF151F11; Wed, 19 Feb 2003 15:13:18 -0500 (EST) To: ietf-sasl@imc.org Subject: Last call for draft-ietf-sasl-anon-00 From: Sam Hartman Date: Wed, 19 Feb 2003 15:13:18 -0500 Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message initiates a SASL Working Group Last Call on the document: Title : The Anonymous SASL Mechanism Editor : K. Zeilenga Filename : draft-ietf-sasl-anon-00.txt The purpose of this WG Last Call is to ensure that the Working Group has achieved consensus that the document is suitable for publication as a Proposed Standard. Please review the document for both technical and editorial problems. Technical issues should be discussed on this list. Editorial issues may be sent to the document editor. The Last Call period will end on Wednesday, March 5, 2003. Upon completion of the last call, the WG chair(s) will take action based upon the consensus of the WG. Possible actions include: 1) recommending to the IETF Security Area Directors that the document, after possible editorial or other minor changes, be considered by the IESG for publication as a Standard Track RFC (which generally involves an IETF-wide Last Call); or 2) requiring that outstanding issues be adequately addressed prior to further action (including, possibly, another WG Last Call). Remember that it is our responsibility as Working Group members to ensure the quality of our documents and of the Internet Standards process. So, please read and comment! - Sam Hartman SASL co-chair From owner-ietf-sasl Thu Feb 20 00:06:03 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1K863G07744 for ietf-sasl-bks; Thu, 20 Feb 2003 00:06:03 -0800 (PST) Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1K862d07739 for ; Thu, 20 Feb 2003 00:06:02 -0800 (PST) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h1K861G17425 for ; Thu, 20 Feb 2003 00:06:01 -0800 (PST) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.6/8.11.6) with ESMTP id h1K87JV13985 for ; Thu, 20 Feb 2003 00:07:19 -0800 (PST) Message-Id: <200302200807.h1K87JV13985@katroo.Sendmail.COM> To: ietf-sasl@imc.org Subject: comments on draft-ietf-sasl-anon-00 Date: Wed, 19 Feb 2003 23:54:04 -0800 From: Philip Guenther Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The syntax for UTF-8 characters in the draft permits "non-shortest form" encodings and encodings for characters outside the range of the Unicode character set. Neither may be interpreted by a program conforming to the Unicode 3.2 specification, which the draft references. Paragraph 5 of section 4 (security consideration), suggests the use of an idle timeout on servers that place a limit on the number of concurrent anonymous users in order to combat a denial-of-service attack. As keeping a connection from being considered idle will generally require simply sending a request (possibly even a malformed request), it's unlikely that an idle timeout will actually prevent an intentional DOS attack from succeeding. A hard timeout on connection duration, network access limitations, or (where appropriate) a limit on the number of requests permitted on an anonymous connection may be required to provide a minimal service guarantee in the face of malicious access. The ANONYMOUS mechanism does not provide a means for the client to supply an optional realm in which the anonymous authentication should take place. This makes the ANONYMOUS mechanism unusable by servers that support multiple realms on a single communication end-point; it cannot supplant the "anonymous@domain" login supported by, for example, some IMAP servers. Philip Guenther From owner-ietf-sasl Thu Feb 20 04:33:52 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KCXq205583 for ietf-sasl-bks; Thu, 20 Feb 2003 04:33:52 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KCXpd05579 for ; Thu, 20 Feb 2003 04:33:51 -0800 (PST) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id h1KCZ8x29392; Thu, 20 Feb 2003 05:35:09 -0700 Message-ID: <3E54CB1B.8FACF46A@messagingdirect.com> Date: Thu, 20 Feb 2003 05:33:31 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Philip Guenther CC: ietf-sasl@imc.org Subject: Re: comments on draft-ietf-sasl-anon-00 References: <200302200807.h1K87JV13985@katroo.Sendmail.COM> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: > The ANONYMOUS mechanism does not provide a means for the client to > supply an optional realm in which the anonymous authentication should > take place. This makes the ANONYMOUS mechanism unusable by servers that > support multiple realms on a single communication end-point; See below. > it cannot supplant the "anonymous@domain" Which conforms to the syntax for "email", isn't it? > login supported by, for example, some IMAP servers. Server is not supposed to verify "email", so anything that looks like "email" just works fine. Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Thu Feb 20 04:41:59 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KCfxS05817 for ietf-sasl-bks; Thu, 20 Feb 2003 04:41:59 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KCfwd05813 for ; Thu, 20 Feb 2003 04:41:58 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09462; Thu, 20 Feb 2003 07:38:09 -0500 (EST) Message-Id: <200302201238.HAA09462@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2831bis-00.txt Date: Thu, 20 Feb 2003 07:38:08 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Using Digest Authentication as a SASL Mechanism Author(s) : P. Leach, C. Newman, A. Melnikov Filename : draft-ietf-sasl-rfc2831bis-00.txt Pages : 35 Date : 2003-2-19 This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2831bis-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2831bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-19142313.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2831bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19142313.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Thu Feb 20 07:20:13 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KFKDC15839 for ietf-sasl-bks; Thu, 20 Feb 2003 07:20:13 -0800 (PST) Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KFKBd15830 for ; Thu, 20 Feb 2003 07:20:12 -0800 (PST) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.7/8.12.7) with ESMTP id h1KFK4Xf023755 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Thu, 20 Feb 2003 16:20:07 +0100 To: ietf-sasl@imc.org Subject: Re: Last call for draft-ietf-sasl-anon-00 X-Payment: hashcash 1.1 0:030220:ietf-sasl@imc.org:414cfd3569157f27 X-Hashcash: 0:030220:ietf-sasl@imc.org:414cfd3569157f27 From: Simon Josefsson Date: Thu, 20 Feb 2003 16:20:04 +0100 In-Reply-To: (Sam Hartman's message of "Wed, 19 Feb 2003 15:13:18 -0500") Message-ID: User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/21.3.50 References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_GNUS_UA version=2.44 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The stringprep profile in section 2 is silent on unassigned code point handling. Perhaps clarify that the list of unassigned code points is empty, if that is indeed what is intended? ,---- RFC 3454 | The list of unassigned code points MUST be given in a profile, and | that list MUST be used by implementations of the profile. `---- From owner-ietf-sasl Thu Feb 20 08:46:41 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KGkfB19262 for ietf-sasl-bks; Thu, 20 Feb 2003 08:46:41 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KGkdd19258 for ; Thu, 20 Feb 2003 08:46:40 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KGkYxH028616; Thu, 20 Feb 2003 16:46:35 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220074940.01a10140@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 08:45:00 -0800 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: Last call for draft-ietf-sasl-anon-00 Cc: ietf-sasl@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 07:20 AM 2/20/2003, Simon Josefsson wrote: >The stringprep profile in section 2 is silent on unassigned code point >handling. Perhaps clarify that the list of unassigned code points is >empty, if that is indeed what is intended? I intended: The list of unassigned code points for this profile is that provided in appendix A of [RFC 3454]. Unassigned code points are not prohibited. Kurt From owner-ietf-sasl Thu Feb 20 10:06:22 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KI6Mc24981 for ietf-sasl-bks; Thu, 20 Feb 2003 10:06:22 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KI6Kd24969 for ; Thu, 20 Feb 2003 10:06:20 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KI69xH029409; Thu, 20 Feb 2003 18:06:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 10:04:34 -0800 To: Philip Guenther From: "Kurt D. Zeilenga" Subject: Unicode/UTF-8 issues (was: comments on draft-ietf-sasl-anon-00) Cc: ietf-sasl@imc.org In-Reply-To: <200302200807.h1K87JV13985@katroo.Sendmail.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:54 PM 2/19/2003, Philip Guenther wrote: >The syntax for UTF-8 characters in the draft permits "non-shortest form" >encodings I'm not exactly sure what you are referring to here. The draft says that the trace information is transferred as string of UTF-8 encoded Unicode characters. A non-shorted form UTF-8 encoding of a Unicode character is invalid per RFC 2247. I believe draft-yergeau-rfc2279bis-04.txt is more clear on this, so I'll change the reference. If, however, you mean that the string of Unicode characters is not normalized using an algorithm which produces the minimum number of code points, yes. This is as intended. >and encodings for characters outside the range of the Unicode >character set. Unassigned code points may be transferred. I will clarify that as I noted in another post. However, I believe the specification is clear that characters "outside the range", e.g. not in the repertoire of characters, are invalid. >Neither may be interpreted by a program conforming to >the Unicode 3.2 specification, which the draft references. Which is exactly why the specification restricts the string to a particular repertoire of characters. Kurt From owner-ietf-sasl Thu Feb 20 10:25:04 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KIP4i27542 for ietf-sasl-bks; Thu, 20 Feb 2003 10:25:04 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KIP2d27535 for ; Thu, 20 Feb 2003 10:25:02 -0800 (PST) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id h1KIQUx00882; Thu, 20 Feb 2003 11:26:30 -0700 Message-ID: <3E551D7A.BFB50CE8@messagingdirect.com> Date: Thu, 20 Feb 2003 11:24:58 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Philip Guenther , ietf-sasl@imc.org Subject: Re: Unicode/UTF-8 issues (was: comments on draft-ietf-sasl-anon-00) References: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" wrote: > At 11:54 PM 2/19/2003, Philip Guenther wrote: > >The syntax for UTF-8 characters in the draft permits "non-shortest form" > >encodings > > I'm not exactly sure what you are referring to here. The > draft says that the trace information is transferred as > string of UTF-8 encoded Unicode characters. A non-shorted > form UTF-8 encoding of a Unicode character is invalid per > RFC 2247. I believe draft-yergeau-rfc2279bis-04.txt is > more clear on this, so I'll change the reference. I believe Philip was referring to ABNF which allows for overlong UTF8 sequences. > If, however, you mean that the string of Unicode characters > is not normalized using an algorithm which produces the > minimum number of code points, yes. This is as intended. Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Thu Feb 20 11:10:43 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KJAhn28968 for ietf-sasl-bks; Thu, 20 Feb 2003 11:10:43 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KJAfd28964 for ; Thu, 20 Feb 2003 11:10:41 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KJAfxH029810; Thu, 20 Feb 2003 19:10:42 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220103201.01a11718@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 11:09:07 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: Unicode/UTF-8 issues (was: comments on draft-ietf-sasl-anon-00) Cc: Philip Guenther , ietf-sasl@imc.org In-Reply-To: <3E551D7A.BFB50CE8@messagingdirect.com> References: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:24 AM 2/20/2003, Alexey Melnikov wrote: >"Kurt D. Zeilenga" wrote: > >> At 11:54 PM 2/19/2003, Philip Guenther wrote: >> >The syntax for UTF-8 characters in the draft permits "non-shortest form" >> >encodings >> >> I'm not exactly sure what you are referring to here. The >> draft says that the trace information is transferred as >> string of UTF-8 encoded Unicode characters. A non-shorted >> form UTF-8 encoding of a Unicode character is invalid per >> RFC 2247. I believe draft-yergeau-rfc2279bis-04.txt is >> more clear on this, so I'll change the reference. > >I believe Philip was referring to ABNF which allows for overlong UTF8 >sequences. I gather that you are saying that ABNF is not precise enough. (please correct me if I wrongly gathered). While I can see that if you ignored all other text and the comments within the ABNF, one could presume that the message, in hex, 0C 30 was valid.... if one actually ignored all the other text and the comments they could also presume that the invalid messages 00 (in hex), foo"bar"@x (in ASCII), and many others were valid. Obviously, the grammar is not intended to be taken out of context. It is provided as a tool for understanding the text of the specification. Kurt From owner-ietf-sasl Thu Feb 20 11:18:54 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KJIsG29250 for ietf-sasl-bks; Thu, 20 Feb 2003 11:18:54 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KJIrd29246 for ; Thu, 20 Feb 2003 11:18:53 -0800 (PST) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id h1KJK8x01507; Thu, 20 Feb 2003 12:20:08 -0700 Message-ID: <3E552A0A.AD59C02B@messagingdirect.com> Date: Thu, 20 Feb 2003 12:18:34 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Philip Guenther , ietf-sasl@imc.org Subject: Re: Unicode/UTF-8 issues (was: comments ondraft-ietf-sasl-anon-00) References: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> <5.2.0.9.0.20030220103201.01a11718@127.0.0.1> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > >I believe Philip was referring to ABNF which allows for overlong UTF8 > >sequences. > > I gather that you are saying that ABNF is not precise enough. Correct. > (please correct me if I wrongly gathered). While I can > see that if you ignored all other text and the comments within > the ABNF, one could presume that the message, in hex, 0C 30 > was valid.... if one actually ignored all the other text > and the comments they could also presume that the invalid > messages 00 (in hex), foo"bar"@x (in ASCII), and many others > were valid. > > Obviously, the grammar is not intended to be taken out of > context. It is provided as a tool for understanding the > text of the specification. I've seen the version of the grammer that deals with overlong sequence. Check draft-yergeau-rfc2279bis-04.txt section 4. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Thu Feb 20 11:31:55 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KJVtm29633 for ietf-sasl-bks; Thu, 20 Feb 2003 11:31:55 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KJVsd29629 for ; Thu, 20 Feb 2003 11:31:54 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KJVtxH030224; Thu, 20 Feb 2003 19:31:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 11:30:21 -0800 To: Philip Guenther From: "Kurt D. Zeilenga" Subject: realms (Was: comments on draft-ietf-sasl-anon-00) Cc: ietf-sasl@imc.org In-Reply-To: <200302200807.h1K87JV13985@katroo.Sendmail.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:54 PM 2/19/2003, Philip Guenther wrote: >The ANONYMOUS mechanism does not provide a means for the client to >supply an optional realm in which the anonymous authentication should >take place. Correct, it doesn't. (The trace information has no semantical value.) >This makes the ANONYMOUS mechanism unusable by servers that >support multiple realms on a single communication end-point; it cannot >supplant the "anonymous@domain" login supported by, for example, some >IMAP servers. Maybe so. Are you asking for the WG to consider adding realm support to ANONYMOUS mechanism? Or asking the WG to consider clarifications to the ANONYMOUS mechanism that it is not applicable in scenarios allowing different anonymous associations to be established? Kurt From owner-ietf-sasl Thu Feb 20 11:56:46 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KJukx01064 for ietf-sasl-bks; Thu, 20 Feb 2003 11:56:46 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KJuid01060 for ; Thu, 20 Feb 2003 11:56:44 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KJujxH030510; Thu, 20 Feb 2003 19:56:46 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220115255.026602a0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 11:55:11 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: Unicode/UTF-8 issues (was: comments ondraft-ietf-sasl-anon-00) Cc: Philip Guenther , ietf-sasl@imc.org In-Reply-To: <3E552A0A.AD59C02B@messagingdirect.com> References: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> <5.2.0.9.0.20030220103201.01a11718@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Okay, how about I replace the grammar and the paragraph before it as follows: A formal grammar for the client message using Augmented BNF [ABNF] is provide below as a tool for understanding this technical specification. message = [ email / token ] ;; MUST be prepared in accordance with Section 2 UTF1 = %x00-3F / %x41-7F ;; less '@' (U+0040) UTF2 = %xC2-DF UTF0 UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / %xF4 %x80-8F 2(UTF0) UTF0 = %x80-BF TCHAR = UTF1 / UTF2 / UTF3 / UTF3 / UTF4 ;; any UTF-8 encoded Unicode character ;; except '@' (U+0040) email = addr-spec ;; as defined in [IMAIL], except with no free ;; insertion of linear-white-space, and the ;; local-part MUST either be entirely enclosed in ;; quotes or entirely unquoted token = 1*255TCHAR and add an appropriate acknowledgement. Kurt From owner-ietf-sasl Thu Feb 20 12:10:08 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKA8j01474 for ietf-sasl-bks; Thu, 20 Feb 2003 12:10:08 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKA6d01470 for ; Thu, 20 Feb 2003 12:10:06 -0800 (PST) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id h1KKBUx02009; Thu, 20 Feb 2003 13:11:30 -0700 Message-ID: <3E553615.C2717C86@messagingdirect.com> Date: Thu, 20 Feb 2003 13:09:57 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Philip Guenther , ietf-sasl@imc.org Subject: Re: Unicode/UTF-8 issues (was: commentsondraft-ietf-sasl-anon-00) References: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> <5.2.0.9.0.20030220103201.01a11718@127.0.0.1> <5.2.0.9.0.20030220115255.026602a0@127.0.0.1> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" wrote: > Okay, how about I replace the grammar and the paragraph before > it as follows: This mostly works, see below. > A formal grammar for the client message using Augmented BNF [ABNF] > is provide below as a tool for understanding this technical > specification. > > message = [ email / token ] > ;; MUST be prepared in accordance with Section 2 > > UTF1 = %x00-3F / %x41-7F ;; less '@' (U+0040) > UTF2 = %xC2-DF UTF0 > UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / > %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) > UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / > %xF4 %x80-8F 2(UTF0) > UTF0 = %x80-BF > > TCHAR = UTF1 / UTF2 / UTF3 / UTF3 / UTF4 > ;; any UTF-8 encoded Unicode character > ;; except '@' (U+0040) Hmm, this suggests a typo in draft-yergeau-rfc2279bis-04.txt (UTF3 is shown twice). Also note, that this doesn't have UTF5 & UTF6 that you currently have: UTF5 = %xF8-FB 4(UTF0) UTF6 = %xFC-FD 5(UTF0) (but they have to be cleaned up to prevent overlong sequences). > email = addr-spec > ;; as defined in [IMAIL], except with no free > ;; insertion of linear-white-space, and the > ;; local-part MUST either be entirely enclosed in > ;; quotes or entirely unquoted > > token = 1*255TCHAR > > and add an appropriate acknowledgement. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Thu Feb 20 12:08:36 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KK8ah01404 for ietf-sasl-bks; Thu, 20 Feb 2003 12:08:36 -0800 (PST) Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KK8Zd01400 for ; Thu, 20 Feb 2003 12:08:35 -0800 (PST) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h1KK8aG24293; Thu, 20 Feb 2003 12:08:36 -0800 (PST) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.6/8.11.6) with ESMTP id h1KK9rV11903; Thu, 20 Feb 2003 12:09:53 -0800 (PST) Message-Id: <200302202009.h1KK9rV11903@katroo.Sendmail.COM> To: "Kurt D. Zeilenga" Cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: Unicode/UTF-8 issues (was: comments on draft-ietf-sasl-anon-00) In-reply-to: <5.2.0.9.0.20030220103201.01a11718@127.0.0.1> References: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> <5.2.0.9.0.20030220103201.01a11718@127.0.0.1> Date: Thu, 20 Feb 2003 11:56:34 -0800 From: Philip Guenther Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: ... >I gather that you are saying that ABNF is not precise enough. >(please correct me if I wrongly gathered). While I can >see that if you ignored all other text and the comments within >the ABNF, one could presume that the message, in hex, 0C 30 >was valid.... if one actually ignored all the other text >and the comments they could also presume that the invalid >messages 00 (in hex), foo"bar"@x (in ASCII), and many others >were valid. No, the latter is not valid by the grammar. My dislike for the current formulation is two-fold: TCHAR, as defined, isn't actually "any UTF-8 encoded Unicode character except '@' (U+0040)" as described in the comment. The UTF5 and UTF6 definitions do not match any legal UTF-8 character and the UTF3 and UTF4 definitions match illegal UTF-8 characters. I would prefer to find all the restrictions on what characters are legal in a token in a single location. The grammar could simply define TCHAR as a UTF-8 encoded character (perhaps using the productions in the draft Alexey mentioned) while the stringprep profile could handle all the restrictions on content at the level of Unicode characters. Yes, this makes the grammar ambiguous, but even rfc2822, the first 'target' for ABNF, has an amibiguous grammar that is only resolved by semantic restrictions in the general text. >Obviously, the grammar is not intended to be taken out of >context. It is provided as a tool for understanding the >text of the specification. As always, clarity and correctness are the goals. IMHO, defining a non-terminal that's neither a superset nor a subset of UTF-8, with additional restrictions elsewhere, makes it more difficult to understand. Philip Guenther From owner-ietf-sasl Thu Feb 20 12:25:11 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKPBK02795 for ietf-sasl-bks; Thu, 20 Feb 2003 12:25:11 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKP9d02788 for ; Thu, 20 Feb 2003 12:25:09 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KKPBxH030925; Thu, 20 Feb 2003 20:25:11 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220115540.026fff98@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 12:23:36 -0800 To: Philip Guenther From: "Kurt D. Zeilenga" Subject: security considerations (was: comments on draft-ietf-sasl-anon-00) Cc: ietf-sasl@imc.org In-Reply-To: <200302200807.h1K87JV13985@katroo.Sendmail.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:54 PM 2/19/2003, Philip Guenther wrote: >Paragraph 5 of section 4 (security consideration), suggests the use of >an idle timeout on servers that place a limit on the number of >concurrent anonymous users in order to combat a denial-of-service >attack. As keeping a connection from being considered idle will >generally require simply sending a request (possibly even a malformed >request), it's unlikely that an idle timeout will actually prevent an >intentional DOS attack from succeeding. A hard timeout on connection >duration, network access limitations, or (where appropriate) a limit on >the number of requests permitted on an anonymous connection may be >required to provide a minimal service guarantee in the face of malicious >access. I'm thinking the problem starts in paragraph 4 with the suggestion that servers should restrict the numbers of anonymous users. How about replacing both paragraph 4 and 5 with: If the anonymous user can run many expensive operations (e.g., an IMAP SEARCH BODY command), this could enable a denial of service attack. Servers are encouraged to reduce the priority of anonymous users or limit their resource usage. While servers may impose a limit on the number of anonymous users, it is noted that such a limit enables denial of service attacks and should be used with caution. From owner-ietf-sasl Thu Feb 20 12:34:27 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKYRm03125 for ietf-sasl-bks; Thu, 20 Feb 2003 12:34:27 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKYQd03120 for ; Thu, 20 Feb 2003 12:34:26 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KKYRxH031004; Thu, 20 Feb 2003 20:34:27 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220123001.026faf68@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 12:32:52 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: Unicode/UTF-8 issues (was: commentsondraft-ietf-sasl-anon-00) Cc: Philip Guenther , ietf-sasl@imc.org In-Reply-To: <3E553615.C2717C86@messagingdirect.com> References: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> <5.2.0.9.0.20030220103201.01a11718@127.0.0.1> <5.2.0.9.0.20030220115255.026602a0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:09 PM 2/20/2003, Alexey Melnikov wrote: >"Kurt D. Zeilenga" wrote: > >> Okay, how about I replace the grammar and the paragraph before >> it as follows: > >This mostly works, see below. > >> A formal grammar for the client message using Augmented BNF [ABNF] >> is provide below as a tool for understanding this technical >> specification. >> >> message = [ email / token ] >> ;; MUST be prepared in accordance with Section 2 >> >> UTF1 = %x00-3F / %x41-7F ;; less '@' (U+0040) >> UTF2 = %xC2-DF UTF0 >> UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / >> %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) >> UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / >> %xF4 %x80-8F 2(UTF0) >> UTF0 = %x80-BF >> >> TCHAR = UTF1 / UTF2 / UTF3 / UTF3 / UTF4 >> ;; any UTF-8 encoded Unicode character >> ;; except '@' (U+0040) > >Hmm, this suggests a typo in draft-yergeau-rfc2279bis-04.txt (UTF3 is >shown twice). Or an error on my part. UTF3 should only be listed once here. >Also note, that this doesn't have UTF5 & UTF6 that you currently have: > > UTF5 = %xF8-FB 4(UTF0) > UTF6 = %xFC-FD 5(UTF0) > >(but they have to be cleaned up to prevent overlong sequences). Yes. There are a couple of 4 v 6 octet cleanups to be made as well. From owner-ietf-sasl Thu Feb 20 12:37:18 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKbIl03209 for ietf-sasl-bks; Thu, 20 Feb 2003 12:37:18 -0800 (PST) Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKbHd03204 for ; Thu, 20 Feb 2003 12:37:17 -0800 (PST) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h1KKbIG27039; Thu, 20 Feb 2003 12:37:18 -0800 (PST) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.6/8.11.6) with ESMTP id h1KKcZV15308; Thu, 20 Feb 2003 12:38:35 -0800 (PST) Message-Id: <200302202038.h1KKcZV15308@katroo.Sendmail.COM> To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) In-reply-to: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> References: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> Date: Thu, 20 Feb 2003 12:25:16 -0800 From: Philip Guenther Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: >At 11:54 PM 2/19/2003, Philip Guenther wrote: ... >>This makes the ANONYMOUS mechanism unusable by servers that >>support multiple realms on a single communication end-point; it cannot >>supplant the "anonymous@domain" login supported by, for example, some >>IMAP servers. > >Maybe so. > >Are you asking for the WG to consider adding realm support >to ANONYMOUS mechanism? Or asking the WG to consider >clarifications to the ANONYMOUS mechanism that it is not >applicable in scenarios allowing different anonymous >associations to be established? The latter, not the former. While a mechanism that supports multiple anonymous identities may have its place in the SASL 'cookbook', I don't currently have a clear idea of what would be generally useful in that direction to suggest changing the current ANONYMOUS mechanism at this time. Philip Guenther From owner-ietf-sasl Thu Feb 20 12:38:43 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKchc03276 for ietf-sasl-bks; Thu, 20 Feb 2003 12:38:43 -0800 (PST) Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKcgd03272 for ; Thu, 20 Feb 2003 12:38:42 -0800 (PST) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h1KKchG27428; Thu, 20 Feb 2003 12:38:43 -0800 (PST) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.6/8.11.6) with ESMTP id h1KKe0V15449; Thu, 20 Feb 2003 12:40:00 -0800 (PST) Message-Id: <200302202040.h1KKe0V15449@katroo.Sendmail.COM> To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org From: Philip Guenther Subject: Re: security considerations (was: comments on draft-ietf-sasl-anon-00) In-reply-to: <5.2.0.9.0.20030220115540.026fff98@127.0.0.1> References: <5.2.0.9.0.20030220115540.026fff98@127.0.0.1> Date: Thu, 20 Feb 2003 12:26:41 -0800 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: ... >I'm thinking the problem starts in paragraph 4 with the >suggestion that servers should restrict the numbers of >anonymous users. How about replacing both paragraph 4 and >5 with: Looks good to me. Philip Guenther From owner-ietf-sasl Thu Feb 20 12:39:29 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKdTm03297 for ietf-sasl-bks; Thu, 20 Feb 2003 12:39:29 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKdRd03293 for ; Thu, 20 Feb 2003 12:39:27 -0800 (PST) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id h1KKemx02427; Thu, 20 Feb 2003 13:40:49 -0700 Message-ID: <3E553CF3.A4913260@messagingdirect.com> Date: Thu, 20 Feb 2003 13:39:15 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Philip Guenther , ietf-sasl@imc.org Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) References: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" wrote: > At 11:54 PM 2/19/2003, Philip Guenther wrote: > >The ANONYMOUS mechanism does not provide a means for the client to > >supply an optional realm in which the anonymous authentication should > >take place. > > Correct, it doesn't. (The trace information has no semantical > value.) > > >This makes the ANONYMOUS mechanism unusable by servers that > >support multiple realms on a single communication end-point; it cannot > >supplant the "anonymous@domain" login supported by, for example, some > >IMAP servers. > > Maybe so. > > Are you asking for the WG to consider adding realm support > to ANONYMOUS mechanism? Just to clarify: the solution can be as simple as saying that domain part of an "email" can be parsed by the server in order to figure out realm. > Or asking the WG to consider > clarifications to the ANONYMOUS mechanism that it is not > applicable in scenarios allowing different anonymous > associations to be established? Cheers, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-sasl Thu Feb 20 12:46:43 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKkhj03560 for ietf-sasl-bks; Thu, 20 Feb 2003 12:46:43 -0800 (PST) Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKkgd03556 for ; Thu, 20 Feb 2003 12:46:42 -0800 (PST) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h1KKkiG28022; Thu, 20 Feb 2003 12:46:44 -0800 (PST) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.6/8.11.6) with ESMTP id h1KKm0V16300; Thu, 20 Feb 2003 12:48:01 -0800 (PST) Message-Id: <200302202048.h1KKm0V16300@katroo.Sendmail.COM> To: Alexey Melnikov Cc: ietf-sasl@imc.org From: Philip Guenther Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) In-reply-to: <3E553CF3.A4913260@messagingdirect.com> References: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> <3E553CF3.A4913260@messagingdirect.com> Date: Thu, 20 Feb 2003 12:34:41 -0800 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >"Kurt D. Zeilenga" wrote: >> At 11:54 PM 2/19/2003, Philip Guenther wrote: >> >The ANONYMOUS mechanism does not provide a means for the client to >> >supply an optional realm in which the anonymous authentication should >> >take place. ... >> Are you asking for the WG to consider adding realm support >> to ANONYMOUS mechanism? > >Just to clarify: the solution can be as simple as saying that domain part >of an "email" can be parsed by the server in order to figure out realm. I don't think an rfc should suggest automated parsing of trace information. Such a practice would arguably make the non-address form a second-class citizen and possibly lead to the use of placeholder addressees when a general text string would have been more appropriate. Philip Guenther From owner-ietf-sasl Thu Feb 20 12:53:59 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKrxe04718 for ietf-sasl-bks; Thu, 20 Feb 2003 12:53:59 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKrwd04710 for ; Thu, 20 Feb 2003 12:53:58 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KKs0xH031382; Thu, 20 Feb 2003 20:54:00 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220125156.01a3ecb0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 12:52:24 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) Cc: Philip Guenther , ietf-sasl@imc.org In-Reply-To: <3E553CF3.A4913260@messagingdirect.com> References: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:39 PM 2/20/2003, Alexey Melnikov wrote: >Just to clarify: the solution can be as simple as saying that domain part >of an "email" can be parsed by the server in order to figure out realm. I would rather clarify that the trace information has no semantical value. Kurt From owner-ietf-sasl Thu Feb 20 12:51:26 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKpQI04259 for ietf-sasl-bks; Thu, 20 Feb 2003 12:51:26 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKpPd04252 for ; Thu, 20 Feb 2003 12:51:25 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KKpRxH031274; Thu, 20 Feb 2003 20:51:27 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220124111.027081b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 12:49:52 -0800 To: Philip Guenther From: "Kurt D. Zeilenga" Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) Cc: ietf-sasl@imc.org In-Reply-To: <200302202038.h1KKcZV15308@katroo.Sendmail.COM> References: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> <5.2.0.9.0.20030220111223.02503718@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:25 PM 2/20/2003, Philip Guenther wrote: >>Are you asking for the WG to consider adding realm support >>to ANONYMOUS mechanism? Or asking the WG to consider >>clarifications to the ANONYMOUS mechanism that it is not >>applicable in scenarios allowing different anonymous >>associations to be established? > >The latter, not the former. Okay. I suggest you (or another proponent of the clarification) offer text for the WG to consider. Kurt From owner-ietf-sasl Fri Feb 21 13:16:19 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1LLGJT24954 for ietf-sasl-bks; Fri, 21 Feb 2003 13:16:19 -0800 (PST) Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1LLGId24948 for ; Fri, 21 Feb 2003 13:16:18 -0800 (PST) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h1LLGJG10247; Fri, 21 Feb 2003 13:16:19 -0800 (PST) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.6/8.11.6) with ESMTP id h1LLHaV17559; Fri, 21 Feb 2003 13:17:37 -0800 (PST) Message-Id: <200302212117.h1LLHaV17559@katroo.Sendmail.COM> To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) In-reply-to: <5.2.0.9.0.20030220124111.027081b8@127.0.0.1> References: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> <5.2.0.9.0.20030220111223.02503718@127.0.0.1> <5.2.0.9.0.20030220124111.027081b8@127.0.0.1> Date: Fri, 21 Feb 2003 13:04:07 -0800 From: Philip Guenther Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: >At 12:25 PM 2/20/2003, Philip Guenther wrote: >>>Are you asking for the WG to consider adding realm support >>>to ANONYMOUS mechanism? Or asking the WG to consider >>>clarifications to the ANONYMOUS mechanism that it is not >>>applicable in scenarios allowing different anonymous >>>associations to be established? >> >>The latter, not the former. > >Okay. I suggest you (or another proponent of the clarification) >offer text for the WG to consider. How about the following sentence for addition to section 1, perhaps right after the 'no security layer' paragraph? "The ANONYMOUS mechanism is not applicable to servers that support multiple anonymous identities and that do not have enough information from before the SASL exchange (for example, from previous protocol exchanges or the connection addresses) to determine which identity to use." Philip Guenther From owner-ietf-sasl Fri Feb 21 13:51:28 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1LLpSe26561 for ietf-sasl-bks; Fri, 21 Feb 2003 13:51:28 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1LLpQd26557 for ; Fri, 21 Feb 2003 13:51:26 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1LLpSxH046054; Fri, 21 Feb 2003 21:51:28 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030221133147.0278b1b0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 21 Feb 2003 13:49:52 -0800 To: Philip Guenther From: "Kurt D. Zeilenga" Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) Cc: ietf-sasl@imc.org In-Reply-To: <200302212117.h1LLHaV17559@katroo.Sendmail.COM> References: <5.2.0.9.0.20030220124111.027081b8@127.0.0.1> <5.2.0.9.0.20030220111223.02503718@127.0.0.1> <5.2.0.9.0.20030220111223.02503718@127.0.0.1> <5.2.0.9.0.20030220124111.027081b8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 01:04 PM 2/21/2003, Philip Guenther wrote: >How about the following sentence for addition to section 1, perhaps >right after the 'no security layer' paragraph? > >"The ANONYMOUS mechanism is not applicable to servers that support > multiple anonymous identities and that do not have enough information > from before the SASL exchange (for example, from previous protocol > exchanges or the connection addresses) to determine which identity to > use." A few comments. I think "anonymous identity" is an oxymoron. And, of course, the ANONYMOUS mechanism is not intended to determine any identity. One possible alternative wording, which would at avoid these issues, would be: The ANONYMOUS mechanism is not applicable where application-level protocols and/or their implementations offer more than one kind/type/level of anonymous associations between the client and the server as the mechanism provides no facility to indicate the kind/type/level of associate desired. No semantics should be associated with the trace information. Kurt From owner-ietf-sasl Fri Feb 21 19:24:30 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1M3OUI05125 for ietf-sasl-bks; Fri, 21 Feb 2003 19:24:30 -0800 (PST) Received: from konishi-polis.mit.edu (STRATTON-FOUR-THIRTY-FOUR.MIT.EDU [18.187.6.179]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1M3OTd05121 for ; Fri, 21 Feb 2003 19:24:30 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 9E3BD151F11; Fri, 21 Feb 2003 22:24:30 -0500 (EST) To: "Kurt D. Zeilenga" Cc: Alexey Melnikov , Philip Guenther , ietf-sasl@imc.org Subject: Re: realms References: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> <5.2.0.9.0.20030220125156.01a3ecb0@127.0.0.1> From: Sam Hartman Date: Fri, 21 Feb 2003 22:24:30 -0500 In-Reply-To: <5.2.0.9.0.20030220125156.01a3ecb0@127.0.0.1> ("Kurt D. Zeilenga"'s message of "Thu, 20 Feb 2003 12:52:24 -0800") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> At 12:39 PM 2/20/2003, Alexey Melnikov wrote: >> Just to clarify: the solution can be as simple as saying that domain part >> of an "email" can be parsed by the server in order to figure out realm. Kurt> I would rather clarify that the trace information has Kurt> no semantical value. Kurt> Kurt I tend to agree that if a clarification is made it should be in the direction of no semantic value for the trace component. This is just another rehash of the authorization name vs authentication name problem all over again. There is exactly one anonymous authentication name in the universe. It may have trace information associated with it but anonymous logins are all the same. The anonymous identity may be authorized for several different authorization identities--these identities may even correspond to different realms. Our current mechanism does not provide a way to express this authorization identity and expanding the mechanism now is probably a bad idea and possible out of scope. It may be appropriate for some future anonymous mechanism to support authorization identity if that is useful. From owner-ietf-sasl Thu Feb 27 04:49:31 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RCnV704093 for ietf-sasl-bks; Thu, 27 Feb 2003 04:49:31 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RCnTY04089 for ; Thu, 27 Feb 2003 04:49:30 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27915; Thu, 27 Feb 2003 07:45:33 -0500 (EST) Message-Id: <200302271245.HAA27915@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-saslprep-00.txt Date: Thu, 27 Feb 2003 07:45:32 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : SASLprep: Stringprep profile for user names and passwords Author(s) : K. Zeilenga Filename : draft-ietf-sasl-saslprep-00.txt Pages : 5 Date : 2003-2-26 This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the 'SASLprep' 'stringprep' profile to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging user names and/or passwords. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-saslprep-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-saslprep-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-26160958.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-saslprep-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-saslprep-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-26160958.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Thu Feb 27 07:57:31 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RFvV015731 for ietf-sasl-bks; Thu, 27 Feb 2003 07:57:31 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RFvTY15723 for ; Thu, 27 Feb 2003 07:57:30 -0800 (PST) Received: from fermi (h24-86-178-58.ed.shawcable.net [24.86.178.58]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id h1RFwwe17103 for ; Thu, 27 Feb 2003 08:58:59 -0700 From: Steve Hole Date: Thu, 27 Feb 2003 08:57:27 -0700 To: ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-ietf-sasl-saslprep-00.txt In-Reply-To: <200302271245.HAA27915@ietf.org> References: <200302271245.HAA27915@ietf.org> Message-ID: X-Mailer: Execmail for Win32 5.1.1 Build (10) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 27 Feb 2003 07:45:32 -0500 Internet-Drafts@ietf.org wrote: > This document describes how to prepare Unicode strings representing > user names and passwords for comparison. The document defines the > 'SASLprep' 'stringprep' profile to be used for both user names and > passwords. This profile is intended to be used by Simple > Authentication and Security Layer (SASL) mechanisms (such as PLAIN, > CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging user > names and/or passwords. It is entirely possible that I have missed some conversation that answers this question ... if so I apologize. Why is this necessary. Those mechanisms that are recommended for use (CRAM-MD5 is effectively deprecated in favour of Digest) support use of UTF8 encoded strings. Why we would need to do anything else for exact comparison purposes? Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 From owner-ietf-sasl Thu Feb 27 11:04:21 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RJ4Lr00777 for ietf-sasl-bks; Thu, 27 Feb 2003 11:04:21 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RJ4JY00772 for ; Thu, 27 Feb 2003 11:04:19 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1RJ4K8q021982; Thu, 27 Feb 2003 19:04:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030227105153.01a04258@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 27 Feb 2003 11:02:39 -0800 To: Steve Hole From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-saslprep-00.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200302271245.HAA27915@ietf.org> <200302271245.HAA27915@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 07:57 AM 2/27/2003, Steve Hole wrote: >On Thu, 27 Feb 2003 07:45:32 -0500 Internet-Drafts@ietf.org wrote: > > >> This document describes how to prepare Unicode strings representing >> user names and passwords for comparison. The document defines the >> 'SASLprep' 'stringprep' profile to be used for both user names and >> passwords. This profile is intended to be used by Simple >> Authentication and Security Layer (SASL) mechanisms (such as PLAIN, >> CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging user >> names and/or passwords. > >It is entirely possible that I have missed some conversation that answers >this question ... if so I apologize. Why is this necessary. Those >mechanisms that are recommended for use (CRAM-MD5 is effectively >deprecated in favour of Digest) support use of UTF8 encoded strings. Why >we would need to do anything else for exact comparison purposes? To ensure that two different, but canonically equivalent, Unicode strings are treated as being the same. Kurt From owner-ietf-sasl Fri Feb 28 04:29:46 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SCTkb09541 for ietf-sasl-bks; Fri, 28 Feb 2003 04:29:46 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SCTjY09537 for ; Fri, 28 Feb 2003 04:29:45 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22735; Fri, 28 Feb 2003 07:25:48 -0500 (EST) Message-Id: <200302281225.HAA22735@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-hansen-sasl-pki-00.txt Date: Fri, 28 Feb 2003 07:25:47 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The PKI SASL Mechanism Author(s) : T. Hansen Filename : draft-hansen-sasl-pki-00.txt Pages : 6 Date : 2003-2-27 This document defines a user/password Simple Authentication and Security Layer(SASL) mechanism called the PKI mechanism. The PKI mechanism is intended to be used in situations where (1) passwords must be encrypted, (2) the password must be recoverable, and (3) using TLS in combination with a SASL mechanism such as PLAIN is inappropriate. NOTE: This document is a straw proposal to see what interest there is in having a SASL mechanism such as this. See the first section below for more information on why this mechanism is needed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hansen-sasl-pki-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hansen-sasl-pki-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hansen-sasl-pki-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-27132918.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hansen-sasl-pki-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hansen-sasl-pki-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-27132918.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Fri Feb 28 09:00:22 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SH0MH24332 for ietf-sasl-bks; Fri, 28 Feb 2003 09:00:22 -0800 (PST) Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SH0LY24326 for ; Fri, 28 Feb 2003 09:00:21 -0800 (PST) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.7/8.12.7) with ESMTP id h1SH0G0r004368; Fri, 28 Feb 2003 12:00:16 -0500 Message-ID: <3E5F962B.E5CADDDA@oceana.com> Date: Fri, 28 Feb 2003 12:02:35 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: tony@att.com CC: SASL mailing list Subject: draft-hansen-sasl-pki-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony, I assume that this is in response to discussions/complaints on ietf-nntp? Can you compare/contrast what you have in mind to Newman's PASSDSS? http://www.alternic.org/drafts/drafts-n-o/draft-newman-sasl-passdss-01.txt -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Fri Feb 28 10:08:46 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SI8kE27753 for ietf-sasl-bks; Fri, 28 Feb 2003 10:08:46 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SI8iY27740 for ; Fri, 28 Feb 2003 10:08:44 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1SI8e8q033102; Fri, 28 Feb 2003 18:08:41 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Feb 2003 10:06:54 -0800 To: tony@att.com From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt Cc: ietf-sasl@imc.org In-Reply-To: <200302281225.HAA22735@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony, What's the advantage of this approach over using TLS+SASL/PLAIN and then just closing TLS gracefully so that remainder of the session is in the clear? Kurt At 04:25 AM 2/28/2003, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : The PKI SASL Mechanism > Author(s) : T. Hansen > Filename : draft-hansen-sasl-pki-00.txt > Pages : 6 > Date : 2003-2-27 > >This document defines a user/password Simple Authentication and >Security Layer(SASL) mechanism called the PKI mechanism. The PKI >mechanism is intended to be used in situations where (1) passwords must >be encrypted, (2) the password must be recoverable, and (3) using TLS in >combination with a SASL mechanism such as PLAIN is inappropriate. >NOTE: This document is a straw proposal to see what interest there >is in having a SASL mechanism such as this. See the first section below >for more information on why this mechanism is needed. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-hansen-sasl-pki-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-hansen-sasl-pki-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-hansen-sasl-pki-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2003-2-27132918.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-hansen-sasl-pki-00.txt > > From owner-ietf-sasl Fri Feb 28 11:01:09 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SJ19701377 for ietf-sasl-bks; Fri, 28 Feb 2003 11:01:09 -0800 (PST) Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SJ18Y01373 for ; Fri, 28 Feb 2003 11:01:08 -0800 (PST) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.7/8.12.7) with ESMTP id h1SJ130r006557; Fri, 28 Feb 2003 14:01:03 -0500 Message-ID: <3E5FB27B.9964C86A@oceana.com> Date: Fri, 28 Feb 2003 14:03:23 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: tony@att.com, ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt References: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" wrote: > > Tony, > > What's the advantage of this approach over using TLS+SASL/PLAIN > and then just closing TLS gracefully so that remainder of the > session is in the clear? Hmm. I always thought that it was implied that TLS would be active until the end of the session. Can this be done gracefully so that both client and server is happy (are there any existing implementations that wouldn't freak)? Who can/should initiate the shutdown? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Fri Feb 28 11:02:52 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SJ2qC01430 for ietf-sasl-bks; Fri, 28 Feb 2003 11:02:52 -0800 (PST) Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SJ2pY01426 for ; Fri, 28 Feb 2003 11:02:51 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp5.andrew.cmu.edu (8.12.7.Beta1/8.12.3.Beta2) with ESMTP id h1SJ2pRI019902; Fri, 28 Feb 2003 14:02:51 -0500 Date: Fri, 28 Feb 2003 14:02:51 -0500 Message-Id: <200302281902.h1SJ2pRI019902@smtp5.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: tony@att.com, "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org In-reply-to: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt References: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Fri, 28 Feb 2003 10:06:54 -0800 From: "Kurt D. Zeilenga" What's the advantage of this approach over using TLS+SASL/PLAIN and then just closing TLS gracefully so that remainder of the session is in the clear? You don't close TLS; you can renegotiate to the NULL cipher. Larry From owner-ietf-sasl Fri Feb 28 11:17:17 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SJHHm03396 for ietf-sasl-bks; Fri, 28 Feb 2003 11:17:17 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SJHFY03389 for ; Fri, 28 Feb 2003 11:17:15 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1SJHF8q033908; Fri, 28 Feb 2003 19:17:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030228110305.01a2ec18@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Feb 2003 11:15:33 -0800 To: Ken Murchison From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt Cc: tony@att.com, ietf-sasl@imc.org In-Reply-To: <3E5FB27B.9964C86A@oceana.com> References: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:03 AM 2/28/2003, Ken Murchison wrote: >"Kurt D. Zeilenga" wrote: >> What's the advantage of this approach over using TLS+SASL/PLAIN >> and then just closing TLS gracefully so that remainder of the >> session is in the clear? > >Hmm. I always thought that it was implied that TLS would be active >until the end of the session. Well, that's maybe how some application-layer protocols specify how TLS is to be used, but TLS does support closure (and subsequent restart). For an example of how one application layer protocol allows TLS closure (and restart), see Section 4.1 of RFC 2830 (LDAPv3 Start TLS). >Can this be done gracefully so that both >client and server is happy (are there any existing implementations that >wouldn't freak)? Yes. But there application-layer issues (such as how to handle outstanding operations, etc.) which need to be address in the technical specification detailing use of TLS in that application-layer protocol. >Who can/should initiate the shutdown? Either TLS peer can issue a closure alert. Kurt From owner-ietf-sasl Fri Feb 28 11:24:10 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SJOAe04545 for ietf-sasl-bks; Fri, 28 Feb 2003 11:24:10 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SJO9Y04539 for ; Fri, 28 Feb 2003 11:24:09 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1SJO78q033959; Fri, 28 Feb 2003 19:24:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030228111727.02a2be70@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Feb 2003 11:22:25 -0800 To: Lawrence Greenfield From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt Cc: tony@att.com, ietf-sasl@imc.org In-Reply-To: <200302281902.h1SJ2pRI019902@smtp5.andrew.cmu.edu> References: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:02 AM 2/28/2003, Lawrence Greenfield wrote: > Date: Fri, 28 Feb 2003 10:06:54 -0800 > From: "Kurt D. Zeilenga" > > What's the advantage of this approach over using TLS+SASL/PLAIN > and then just closing TLS gracefully so that remainder of the > session is in the clear? > >You don't close TLS; you can renegotiate to the NULL cipher. Application-level protocols may permit use the stream after TLS closure. See RFC 2246, Section 7.2.1. LDAPv3 is an example, RFC 2830, of an application-level protocol which explicitly permits such use. Kurt From owner-ietf-sasl Fri Feb 28 11:46:39 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SJkdv06560 for ietf-sasl-bks; Fri, 28 Feb 2003 11:46:39 -0800 (PST) Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SJkbY06555 for ; Fri, 28 Feb 2003 11:46:37 -0800 (PST) Received: from maillennium.att.com ([135.25.114.99]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h1SJkSWJ005692 for ; Fri, 28 Feb 2003 13:46:28 -0600 (CST) Received: from att.com ([135.210.10.156]) by maillennium.att.com (mailgw1) with SMTP id <20030228194547gw100kselme> (Authid: tony); Fri, 28 Feb 2003 19:45:47 +0000 Message-ID: <3E5FBC71.9070700@att.com> Date: Fri, 28 Feb 2003 14:45:53 -0500 From: Tony Hansen User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt References: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> In-Reply-To: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All the application protocols have a way of saying "I want to turn TLS on", but none of the application protocols have a way to say "now I want to turn TLS off". I even think that the "start TLS" specs in most application protocols explicitly say that you CANNOT switch it back off. Within the TLS layer, you can negotiate switching to a null cipher. But there is no way to mandate that up at the application protocol level. Plus I think there're still other overheads of TLS that don't go away. Tony Hansen tony@att.com Kurt D. Zeilenga wrote: > What's the advantage of this approach over using TLS+SASL/PLAIN > and then just closing TLS gracefully so that remainder of the > session is in the clear? From owner-ietf-sasl Fri Feb 28 12:41:32 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SKfWu08417 for ietf-sasl-bks; Fri, 28 Feb 2003 12:41:32 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SKfVY08413 for ; Fri, 28 Feb 2003 12:41:31 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1SKfV8q034488; Fri, 28 Feb 2003 20:41:31 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030228121133.01a0f518@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Feb 2003 12:39:49 -0800 To: Tony Hansen From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt Cc: ietf-sasl@imc.org In-Reply-To: <3E5FBC71.9070700@att.com> References: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:45 AM 2/28/2003, Tony Hansen wrote: >All the application protocols have a way of saying "I want to turn TLS on", >but none of the application protocols have a way to say "now I want to turn TLS off". TLS closure alert says "I want to turn TLS off". Every application protocol which profiles TLS should state what happens when this is said. >I even think that the "start TLS" specs in most application protocols explicitly say that you CANNOT switch it back off. I suspect most application protocol specifications are mute on what to do upon TLS closure. Anyways, it seems what you are saying is, you need a new mechanism because some application protocol profiles of TLS don't allow messages to be exchanged post TLS closure. I would add, and where they do allow such, not all implementations support it. I suggest briefly discuss in your draft why a TLS+SASL/PLAIN+closure approach is not well suited to your needs. >Within the TLS layer, you can negotiate switching to a null cipher. But there is no way to mandate that up at the application protocol level. Most TLS implementations I know provide applications with adequate control over which cipher suites may be used, as well as which cipher suite is in use, so that they may ensure they can enforce applicable security policies. >Plus I think there're still other overheads of TLS that don't go away. I would think that a good TLS implementation would have minimal overhead when a null cipher suite was in use. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SKfWu08417 for ietf-sasl-bks; Fri, 28 Feb 2003 12:41:32 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SKfVY08413 for ; Fri, 28 Feb 2003 12:41:31 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1SKfV8q034488; Fri, 28 Feb 2003 20:41:31 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030228121133.01a0f518@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Feb 2003 12:39:49 -0800 To: Tony Hansen From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt Cc: ietf-sasl@imc.org In-Reply-To: <3E5FBC71.9070700@att.com> References: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:45 AM 2/28/2003, Tony Hansen wrote: >All the application protocols have a way of saying "I want to turn TLS on", >but none of the application protocols have a way to say "now I want to turn TLS off". TLS closure alert says "I want to turn TLS off". Every application protocol which profiles TLS should state what happens when this is said. >I even think that the "start TLS" specs in most application protocols explicitly say that you CANNOT switch it back off. I suspect most application protocol specifications are mute on what to do upon TLS closure. Anyways, it seems what you are saying is, you need a new mechanism because some application protocol profiles of TLS don't allow messages to be exchanged post TLS closure. I would add, and where they do allow such, not all implementations support it. I suggest briefly discuss in your draft why a TLS+SASL/PLAIN+closure approach is not well suited to your needs. >Within the TLS layer, you can negotiate switching to a null cipher. But there is no way to mandate that up at the application protocol level. Most TLS implementations I know provide applications with adequate control over which cipher suites may be used, as well as which cipher suite is in use, so that they may ensure they can enforce applicable security policies. >Plus I think there're still other overheads of TLS that don't go away. I would think that a good TLS implementation would have minimal overhead when a null cipher suite was in use. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SJkdv06560 for ietf-sasl-bks; Fri, 28 Feb 2003 11:46:39 -0800 (PST) Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SJkbY06555 for ; Fri, 28 Feb 2003 11:46:37 -0800 (PST) Received: from maillennium.att.com ([135.25.114.99]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h1SJkSWJ005692 for ; Fri, 28 Feb 2003 13:46:28 -0600 (CST) Received: from att.com ([135.210.10.156]) by maillennium.att.com (mailgw1) with SMTP id <20030228194547gw100kselme> (Authid: tony); Fri, 28 Feb 2003 19:45:47 +0000 Message-ID: <3E5FBC71.9070700@att.com> Date: Fri, 28 Feb 2003 14:45:53 -0500 From: Tony Hansen User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt References: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> In-Reply-To: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All the application protocols have a way of saying "I want to turn TLS on", but none of the application protocols have a way to say "now I want to turn TLS off". I even think that the "start TLS" specs in most application protocols explicitly say that you CANNOT switch it back off. Within the TLS layer, you can negotiate switching to a null cipher. But there is no way to mandate that up at the application protocol level. Plus I think there're still other overheads of TLS that don't go away. Tony Hansen tony@att.com Kurt D. Zeilenga wrote: > What's the advantage of this approach over using TLS+SASL/PLAIN > and then just closing TLS gracefully so that remainder of the > session is in the clear? Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SJOAe04545 for ietf-sasl-bks; Fri, 28 Feb 2003 11:24:10 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SJO9Y04539 for ; Fri, 28 Feb 2003 11:24:09 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1SJO78q033959; Fri, 28 Feb 2003 19:24:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030228111727.02a2be70@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Feb 2003 11:22:25 -0800 To: Lawrence Greenfield From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt Cc: tony@att.com, ietf-sasl@imc.org In-Reply-To: <200302281902.h1SJ2pRI019902@smtp5.andrew.cmu.edu> References: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:02 AM 2/28/2003, Lawrence Greenfield wrote: > Date: Fri, 28 Feb 2003 10:06:54 -0800 > From: "Kurt D. Zeilenga" > > What's the advantage of this approach over using TLS+SASL/PLAIN > and then just closing TLS gracefully so that remainder of the > session is in the clear? > >You don't close TLS; you can renegotiate to the NULL cipher. Application-level protocols may permit use the stream after TLS closure. See RFC 2246, Section 7.2.1. LDAPv3 is an example, RFC 2830, of an application-level protocol which explicitly permits such use. Kurt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SJHHm03396 for ietf-sasl-bks; Fri, 28 Feb 2003 11:17:17 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SJHFY03389 for ; Fri, 28 Feb 2003 11:17:15 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1SJHF8q033908; Fri, 28 Feb 2003 19:17:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030228110305.01a2ec18@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Feb 2003 11:15:33 -0800 To: Ken Murchison From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt Cc: tony@att.com, ietf-sasl@imc.org In-Reply-To: <3E5FB27B.9964C86A@oceana.com> References: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:03 AM 2/28/2003, Ken Murchison wrote: >"Kurt D. Zeilenga" wrote: >> What's the advantage of this approach over using TLS+SASL/PLAIN >> and then just closing TLS gracefully so that remainder of the >> session is in the clear? > >Hmm. I always thought that it was implied that TLS would be active >until the end of the session. Well, that's maybe how some application-layer protocols specify how TLS is to be used, but TLS does support closure (and subsequent restart). For an example of how one application layer protocol allows TLS closure (and restart), see Section 4.1 of RFC 2830 (LDAPv3 Start TLS). >Can this be done gracefully so that both >client and server is happy (are there any existing implementations that >wouldn't freak)? Yes. But there application-layer issues (such as how to handle outstanding operations, etc.) which need to be address in the technical specification detailing use of TLS in that application-layer protocol. >Who can/should initiate the shutdown? Either TLS peer can issue a closure alert. Kurt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SJ2qC01430 for ietf-sasl-bks; Fri, 28 Feb 2003 11:02:52 -0800 (PST) Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SJ2pY01426 for ; Fri, 28 Feb 2003 11:02:51 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp5.andrew.cmu.edu (8.12.7.Beta1/8.12.3.Beta2) with ESMTP id h1SJ2pRI019902; Fri, 28 Feb 2003 14:02:51 -0500 Date: Fri, 28 Feb 2003 14:02:51 -0500 Message-Id: <200302281902.h1SJ2pRI019902@smtp5.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: tony@att.com, "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org In-reply-to: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt References: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Fri, 28 Feb 2003 10:06:54 -0800 From: "Kurt D. Zeilenga" What's the advantage of this approach over using TLS+SASL/PLAIN and then just closing TLS gracefully so that remainder of the session is in the clear? You don't close TLS; you can renegotiate to the NULL cipher. Larry Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SJ19701377 for ietf-sasl-bks; Fri, 28 Feb 2003 11:01:09 -0800 (PST) Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SJ18Y01373 for ; Fri, 28 Feb 2003 11:01:08 -0800 (PST) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.7/8.12.7) with ESMTP id h1SJ130r006557; Fri, 28 Feb 2003 14:01:03 -0500 Message-ID: <3E5FB27B.9964C86A@oceana.com> Date: Fri, 28 Feb 2003 14:03:23 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: tony@att.com, ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt References: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" wrote: > > Tony, > > What's the advantage of this approach over using TLS+SASL/PLAIN > and then just closing TLS gracefully so that remainder of the > session is in the clear? Hmm. I always thought that it was implied that TLS would be active until the end of the session. Can this be done gracefully so that both client and server is happy (are there any existing implementations that wouldn't freak)? Who can/should initiate the shutdown? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SI8kE27753 for ietf-sasl-bks; Fri, 28 Feb 2003 10:08:46 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SI8iY27740 for ; Fri, 28 Feb 2003 10:08:44 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1SI8e8q033102; Fri, 28 Feb 2003 18:08:41 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030228095736.01a130b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Feb 2003 10:06:54 -0800 To: tony@att.com From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt Cc: ietf-sasl@imc.org In-Reply-To: <200302281225.HAA22735@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony, What's the advantage of this approach over using TLS+SASL/PLAIN and then just closing TLS gracefully so that remainder of the session is in the clear? Kurt At 04:25 AM 2/28/2003, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : The PKI SASL Mechanism > Author(s) : T. Hansen > Filename : draft-hansen-sasl-pki-00.txt > Pages : 6 > Date : 2003-2-27 > >This document defines a user/password Simple Authentication and >Security Layer(SASL) mechanism called the PKI mechanism. The PKI >mechanism is intended to be used in situations where (1) passwords must >be encrypted, (2) the password must be recoverable, and (3) using TLS in >combination with a SASL mechanism such as PLAIN is inappropriate. >NOTE: This document is a straw proposal to see what interest there >is in having a SASL mechanism such as this. See the first section below >for more information on why this mechanism is needed. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-hansen-sasl-pki-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-hansen-sasl-pki-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-hansen-sasl-pki-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2003-2-27132918.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-hansen-sasl-pki-00.txt > > Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SH0MH24332 for ietf-sasl-bks; Fri, 28 Feb 2003 09:00:22 -0800 (PST) Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SH0LY24326 for ; Fri, 28 Feb 2003 09:00:21 -0800 (PST) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.7/8.12.7) with ESMTP id h1SH0G0r004368; Fri, 28 Feb 2003 12:00:16 -0500 Message-ID: <3E5F962B.E5CADDDA@oceana.com> Date: Fri, 28 Feb 2003 12:02:35 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: tony@att.com CC: SASL mailing list Subject: draft-hansen-sasl-pki-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony, I assume that this is in response to discussions/complaints on ietf-nntp? Can you compare/contrast what you have in mind to Newman's PASSDSS? http://www.alternic.org/drafts/drafts-n-o/draft-newman-sasl-passdss-01.txt -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SCTkb09541 for ietf-sasl-bks; Fri, 28 Feb 2003 04:29:46 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SCTjY09537 for ; Fri, 28 Feb 2003 04:29:45 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22735; Fri, 28 Feb 2003 07:25:48 -0500 (EST) Message-Id: <200302281225.HAA22735@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-hansen-sasl-pki-00.txt Date: Fri, 28 Feb 2003 07:25:47 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The PKI SASL Mechanism Author(s) : T. Hansen Filename : draft-hansen-sasl-pki-00.txt Pages : 6 Date : 2003-2-27 This document defines a user/password Simple Authentication and Security Layer(SASL) mechanism called the PKI mechanism. The PKI mechanism is intended to be used in situations where (1) passwords must be encrypted, (2) the password must be recoverable, and (3) using TLS in combination with a SASL mechanism such as PLAIN is inappropriate. NOTE: This document is a straw proposal to see what interest there is in having a SASL mechanism such as this. See the first section below for more information on why this mechanism is needed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hansen-sasl-pki-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hansen-sasl-pki-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hansen-sasl-pki-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-27132918.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hansen-sasl-pki-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hansen-sasl-pki-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-27132918.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RJ4Lr00777 for ietf-sasl-bks; Thu, 27 Feb 2003 11:04:21 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RJ4JY00772 for ; Thu, 27 Feb 2003 11:04:19 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1RJ4K8q021982; Thu, 27 Feb 2003 19:04:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030227105153.01a04258@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 27 Feb 2003 11:02:39 -0800 To: Steve Hole From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-saslprep-00.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200302271245.HAA27915@ietf.org> <200302271245.HAA27915@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 07:57 AM 2/27/2003, Steve Hole wrote: >On Thu, 27 Feb 2003 07:45:32 -0500 Internet-Drafts@ietf.org wrote: > > >> This document describes how to prepare Unicode strings representing >> user names and passwords for comparison. The document defines the >> 'SASLprep' 'stringprep' profile to be used for both user names and >> passwords. This profile is intended to be used by Simple >> Authentication and Security Layer (SASL) mechanisms (such as PLAIN, >> CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging user >> names and/or passwords. > >It is entirely possible that I have missed some conversation that answers >this question ... if so I apologize. Why is this necessary. Those >mechanisms that are recommended for use (CRAM-MD5 is effectively >deprecated in favour of Digest) support use of UTF8 encoded strings. Why >we would need to do anything else for exact comparison purposes? To ensure that two different, but canonically equivalent, Unicode strings are treated as being the same. Kurt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RFvV015731 for ietf-sasl-bks; Thu, 27 Feb 2003 07:57:31 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RFvTY15723 for ; Thu, 27 Feb 2003 07:57:30 -0800 (PST) Received: from fermi (h24-86-178-58.ed.shawcable.net [24.86.178.58]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id h1RFwwe17103 for ; Thu, 27 Feb 2003 08:58:59 -0700 From: Steve Hole Date: Thu, 27 Feb 2003 08:57:27 -0700 To: ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-ietf-sasl-saslprep-00.txt In-Reply-To: <200302271245.HAA27915@ietf.org> References: <200302271245.HAA27915@ietf.org> Message-ID: X-Mailer: Execmail for Win32 5.1.1 Build (10) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 27 Feb 2003 07:45:32 -0500 Internet-Drafts@ietf.org wrote: > This document describes how to prepare Unicode strings representing > user names and passwords for comparison. The document defines the > 'SASLprep' 'stringprep' profile to be used for both user names and > passwords. This profile is intended to be used by Simple > Authentication and Security Layer (SASL) mechanisms (such as PLAIN, > CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging user > names and/or passwords. It is entirely possible that I have missed some conversation that answers this question ... if so I apologize. Why is this necessary. Those mechanisms that are recommended for use (CRAM-MD5 is effectively deprecated in favour of Digest) support use of UTF8 encoded strings. Why we would need to do anything else for exact comparison purposes? Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RCnV704093 for ietf-sasl-bks; Thu, 27 Feb 2003 04:49:31 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RCnTY04089 for ; Thu, 27 Feb 2003 04:49:30 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27915; Thu, 27 Feb 2003 07:45:33 -0500 (EST) Message-Id: <200302271245.HAA27915@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-saslprep-00.txt Date: Thu, 27 Feb 2003 07:45:32 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : SASLprep: Stringprep profile for user names and passwords Author(s) : K. Zeilenga Filename : draft-ietf-sasl-saslprep-00.txt Pages : 5 Date : 2003-2-26 This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the 'SASLprep' 'stringprep' profile to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging user names and/or passwords. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-saslprep-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-saslprep-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-26160958.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-saslprep-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-saslprep-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-26160958.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1M3OUI05125 for ietf-sasl-bks; Fri, 21 Feb 2003 19:24:30 -0800 (PST) Received: from konishi-polis.mit.edu (STRATTON-FOUR-THIRTY-FOUR.MIT.EDU [18.187.6.179]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1M3OTd05121 for ; Fri, 21 Feb 2003 19:24:30 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 9E3BD151F11; Fri, 21 Feb 2003 22:24:30 -0500 (EST) To: "Kurt D. Zeilenga" Cc: Alexey Melnikov , Philip Guenther , ietf-sasl@imc.org Subject: Re: realms References: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> <5.2.0.9.0.20030220125156.01a3ecb0@127.0.0.1> From: Sam Hartman Date: Fri, 21 Feb 2003 22:24:30 -0500 In-Reply-To: <5.2.0.9.0.20030220125156.01a3ecb0@127.0.0.1> ("Kurt D. Zeilenga"'s message of "Thu, 20 Feb 2003 12:52:24 -0800") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> At 12:39 PM 2/20/2003, Alexey Melnikov wrote: >> Just to clarify: the solution can be as simple as saying that domain part >> of an "email" can be parsed by the server in order to figure out realm. Kurt> I would rather clarify that the trace information has Kurt> no semantical value. Kurt> Kurt I tend to agree that if a clarification is made it should be in the direction of no semantic value for the trace component. This is just another rehash of the authorization name vs authentication name problem all over again. There is exactly one anonymous authentication name in the universe. It may have trace information associated with it but anonymous logins are all the same. The anonymous identity may be authorized for several different authorization identities--these identities may even correspond to different realms. Our current mechanism does not provide a way to express this authorization identity and expanding the mechanism now is probably a bad idea and possible out of scope. It may be appropriate for some future anonymous mechanism to support authorization identity if that is useful. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1LLpSe26561 for ietf-sasl-bks; Fri, 21 Feb 2003 13:51:28 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1LLpQd26557 for ; Fri, 21 Feb 2003 13:51:26 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1LLpSxH046054; Fri, 21 Feb 2003 21:51:28 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030221133147.0278b1b0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 21 Feb 2003 13:49:52 -0800 To: Philip Guenther From: "Kurt D. Zeilenga" Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) Cc: ietf-sasl@imc.org In-Reply-To: <200302212117.h1LLHaV17559@katroo.Sendmail.COM> References: <5.2.0.9.0.20030220124111.027081b8@127.0.0.1> <5.2.0.9.0.20030220111223.02503718@127.0.0.1> <5.2.0.9.0.20030220111223.02503718@127.0.0.1> <5.2.0.9.0.20030220124111.027081b8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 01:04 PM 2/21/2003, Philip Guenther wrote: >How about the following sentence for addition to section 1, perhaps >right after the 'no security layer' paragraph? > >"The ANONYMOUS mechanism is not applicable to servers that support > multiple anonymous identities and that do not have enough information > from before the SASL exchange (for example, from previous protocol > exchanges or the connection addresses) to determine which identity to > use." A few comments. I think "anonymous identity" is an oxymoron. And, of course, the ANONYMOUS mechanism is not intended to determine any identity. One possible alternative wording, which would at avoid these issues, would be: The ANONYMOUS mechanism is not applicable where application-level protocols and/or their implementations offer more than one kind/type/level of anonymous associations between the client and the server as the mechanism provides no facility to indicate the kind/type/level of associate desired. No semantics should be associated with the trace information. Kurt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1LLGJT24954 for ietf-sasl-bks; Fri, 21 Feb 2003 13:16:19 -0800 (PST) Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1LLGId24948 for ; Fri, 21 Feb 2003 13:16:18 -0800 (PST) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h1LLGJG10247; Fri, 21 Feb 2003 13:16:19 -0800 (PST) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.6/8.11.6) with ESMTP id h1LLHaV17559; Fri, 21 Feb 2003 13:17:37 -0800 (PST) Message-Id: <200302212117.h1LLHaV17559@katroo.Sendmail.COM> To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) In-reply-to: <5.2.0.9.0.20030220124111.027081b8@127.0.0.1> References: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> <5.2.0.9.0.20030220111223.02503718@127.0.0.1> <5.2.0.9.0.20030220124111.027081b8@127.0.0.1> Date: Fri, 21 Feb 2003 13:04:07 -0800 From: Philip Guenther Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: >At 12:25 PM 2/20/2003, Philip Guenther wrote: >>>Are you asking for the WG to consider adding realm support >>>to ANONYMOUS mechanism? Or asking the WG to consider >>>clarifications to the ANONYMOUS mechanism that it is not >>>applicable in scenarios allowing different anonymous >>>associations to be established? >> >>The latter, not the former. > >Okay. I suggest you (or another proponent of the clarification) >offer text for the WG to consider. How about the following sentence for addition to section 1, perhaps right after the 'no security layer' paragraph? "The ANONYMOUS mechanism is not applicable to servers that support multiple anonymous identities and that do not have enough information from before the SASL exchange (for example, from previous protocol exchanges or the connection addresses) to determine which identity to use." Philip Guenther Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKrxe04718 for ietf-sasl-bks; Thu, 20 Feb 2003 12:53:59 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKrwd04710 for ; Thu, 20 Feb 2003 12:53:58 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KKs0xH031382; Thu, 20 Feb 2003 20:54:00 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220125156.01a3ecb0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 12:52:24 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) Cc: Philip Guenther , ietf-sasl@imc.org In-Reply-To: <3E553CF3.A4913260@messagingdirect.com> References: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:39 PM 2/20/2003, Alexey Melnikov wrote: >Just to clarify: the solution can be as simple as saying that domain part >of an "email" can be parsed by the server in order to figure out realm. I would rather clarify that the trace information has no semantical value. Kurt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKpQI04259 for ietf-sasl-bks; Thu, 20 Feb 2003 12:51:26 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKpPd04252 for ; Thu, 20 Feb 2003 12:51:25 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KKpRxH031274; Thu, 20 Feb 2003 20:51:27 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220124111.027081b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 12:49:52 -0800 To: Philip Guenther From: "Kurt D. Zeilenga" Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) Cc: ietf-sasl@imc.org In-Reply-To: <200302202038.h1KKcZV15308@katroo.Sendmail.COM> References: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> <5.2.0.9.0.20030220111223.02503718@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:25 PM 2/20/2003, Philip Guenther wrote: >>Are you asking for the WG to consider adding realm support >>to ANONYMOUS mechanism? Or asking the WG to consider >>clarifications to the ANONYMOUS mechanism that it is not >>applicable in scenarios allowing different anonymous >>associations to be established? > >The latter, not the former. Okay. I suggest you (or another proponent of the clarification) offer text for the WG to consider. Kurt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKkhj03560 for ietf-sasl-bks; Thu, 20 Feb 2003 12:46:43 -0800 (PST) Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKkgd03556 for ; Thu, 20 Feb 2003 12:46:42 -0800 (PST) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h1KKkiG28022; Thu, 20 Feb 2003 12:46:44 -0800 (PST) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.6/8.11.6) with ESMTP id h1KKm0V16300; Thu, 20 Feb 2003 12:48:01 -0800 (PST) Message-Id: <200302202048.h1KKm0V16300@katroo.Sendmail.COM> To: Alexey Melnikov Cc: ietf-sasl@imc.org From: Philip Guenther Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) In-reply-to: <3E553CF3.A4913260@messagingdirect.com> References: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> <3E553CF3.A4913260@messagingdirect.com> Date: Thu, 20 Feb 2003 12:34:41 -0800 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >"Kurt D. Zeilenga" wrote: >> At 11:54 PM 2/19/2003, Philip Guenther wrote: >> >The ANONYMOUS mechanism does not provide a means for the client to >> >supply an optional realm in which the anonymous authentication should >> >take place. ... >> Are you asking for the WG to consider adding realm support >> to ANONYMOUS mechanism? > >Just to clarify: the solution can be as simple as saying that domain part >of an "email" can be parsed by the server in order to figure out realm. I don't think an rfc should suggest automated parsing of trace information. Such a practice would arguably make the non-address form a second-class citizen and possibly lead to the use of placeholder addressees when a general text string would have been more appropriate. Philip Guenther Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKdTm03297 for ietf-sasl-bks; Thu, 20 Feb 2003 12:39:29 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKdRd03293 for ; Thu, 20 Feb 2003 12:39:27 -0800 (PST) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id h1KKemx02427; Thu, 20 Feb 2003 13:40:49 -0700 Message-ID: <3E553CF3.A4913260@messagingdirect.com> Date: Thu, 20 Feb 2003 13:39:15 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Philip Guenther , ietf-sasl@imc.org Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) References: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" wrote: > At 11:54 PM 2/19/2003, Philip Guenther wrote: > >The ANONYMOUS mechanism does not provide a means for the client to > >supply an optional realm in which the anonymous authentication should > >take place. > > Correct, it doesn't. (The trace information has no semantical > value.) > > >This makes the ANONYMOUS mechanism unusable by servers that > >support multiple realms on a single communication end-point; it cannot > >supplant the "anonymous@domain" login supported by, for example, some > >IMAP servers. > > Maybe so. > > Are you asking for the WG to consider adding realm support > to ANONYMOUS mechanism? Just to clarify: the solution can be as simple as saying that domain part of an "email" can be parsed by the server in order to figure out realm. > Or asking the WG to consider > clarifications to the ANONYMOUS mechanism that it is not > applicable in scenarios allowing different anonymous > associations to be established? Cheers, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKchc03276 for ietf-sasl-bks; Thu, 20 Feb 2003 12:38:43 -0800 (PST) Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKcgd03272 for ; Thu, 20 Feb 2003 12:38:42 -0800 (PST) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h1KKchG27428; Thu, 20 Feb 2003 12:38:43 -0800 (PST) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.6/8.11.6) with ESMTP id h1KKe0V15449; Thu, 20 Feb 2003 12:40:00 -0800 (PST) Message-Id: <200302202040.h1KKe0V15449@katroo.Sendmail.COM> To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org From: Philip Guenther Subject: Re: security considerations (was: comments on draft-ietf-sasl-anon-00) In-reply-to: <5.2.0.9.0.20030220115540.026fff98@127.0.0.1> References: <5.2.0.9.0.20030220115540.026fff98@127.0.0.1> Date: Thu, 20 Feb 2003 12:26:41 -0800 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: ... >I'm thinking the problem starts in paragraph 4 with the >suggestion that servers should restrict the numbers of >anonymous users. How about replacing both paragraph 4 and >5 with: Looks good to me. Philip Guenther Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKbIl03209 for ietf-sasl-bks; Thu, 20 Feb 2003 12:37:18 -0800 (PST) Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKbHd03204 for ; Thu, 20 Feb 2003 12:37:17 -0800 (PST) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h1KKbIG27039; Thu, 20 Feb 2003 12:37:18 -0800 (PST) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.6/8.11.6) with ESMTP id h1KKcZV15308; Thu, 20 Feb 2003 12:38:35 -0800 (PST) Message-Id: <200302202038.h1KKcZV15308@katroo.Sendmail.COM> To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) In-reply-to: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> References: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> Date: Thu, 20 Feb 2003 12:25:16 -0800 From: Philip Guenther Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: >At 11:54 PM 2/19/2003, Philip Guenther wrote: ... >>This makes the ANONYMOUS mechanism unusable by servers that >>support multiple realms on a single communication end-point; it cannot >>supplant the "anonymous@domain" login supported by, for example, some >>IMAP servers. > >Maybe so. > >Are you asking for the WG to consider adding realm support >to ANONYMOUS mechanism? Or asking the WG to consider >clarifications to the ANONYMOUS mechanism that it is not >applicable in scenarios allowing different anonymous >associations to be established? The latter, not the former. While a mechanism that supports multiple anonymous identities may have its place in the SASL 'cookbook', I don't currently have a clear idea of what would be generally useful in that direction to suggest changing the current ANONYMOUS mechanism at this time. Philip Guenther Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKYRm03125 for ietf-sasl-bks; Thu, 20 Feb 2003 12:34:27 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKYQd03120 for ; Thu, 20 Feb 2003 12:34:26 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KKYRxH031004; Thu, 20 Feb 2003 20:34:27 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220123001.026faf68@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 12:32:52 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: Unicode/UTF-8 issues (was: commentsondraft-ietf-sasl-anon-00) Cc: Philip Guenther , ietf-sasl@imc.org In-Reply-To: <3E553615.C2717C86@messagingdirect.com> References: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> <5.2.0.9.0.20030220103201.01a11718@127.0.0.1> <5.2.0.9.0.20030220115255.026602a0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:09 PM 2/20/2003, Alexey Melnikov wrote: >"Kurt D. Zeilenga" wrote: > >> Okay, how about I replace the grammar and the paragraph before >> it as follows: > >This mostly works, see below. > >> A formal grammar for the client message using Augmented BNF [ABNF] >> is provide below as a tool for understanding this technical >> specification. >> >> message = [ email / token ] >> ;; MUST be prepared in accordance with Section 2 >> >> UTF1 = %x00-3F / %x41-7F ;; less '@' (U+0040) >> UTF2 = %xC2-DF UTF0 >> UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / >> %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) >> UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / >> %xF4 %x80-8F 2(UTF0) >> UTF0 = %x80-BF >> >> TCHAR = UTF1 / UTF2 / UTF3 / UTF3 / UTF4 >> ;; any UTF-8 encoded Unicode character >> ;; except '@' (U+0040) > >Hmm, this suggests a typo in draft-yergeau-rfc2279bis-04.txt (UTF3 is >shown twice). Or an error on my part. UTF3 should only be listed once here. >Also note, that this doesn't have UTF5 & UTF6 that you currently have: > > UTF5 = %xF8-FB 4(UTF0) > UTF6 = %xFC-FD 5(UTF0) > >(but they have to be cleaned up to prevent overlong sequences). Yes. There are a couple of 4 v 6 octet cleanups to be made as well. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKPBK02795 for ietf-sasl-bks; Thu, 20 Feb 2003 12:25:11 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKP9d02788 for ; Thu, 20 Feb 2003 12:25:09 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KKPBxH030925; Thu, 20 Feb 2003 20:25:11 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220115540.026fff98@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 12:23:36 -0800 To: Philip Guenther From: "Kurt D. Zeilenga" Subject: security considerations (was: comments on draft-ietf-sasl-anon-00) Cc: ietf-sasl@imc.org In-Reply-To: <200302200807.h1K87JV13985@katroo.Sendmail.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:54 PM 2/19/2003, Philip Guenther wrote: >Paragraph 5 of section 4 (security consideration), suggests the use of >an idle timeout on servers that place a limit on the number of >concurrent anonymous users in order to combat a denial-of-service >attack. As keeping a connection from being considered idle will >generally require simply sending a request (possibly even a malformed >request), it's unlikely that an idle timeout will actually prevent an >intentional DOS attack from succeeding. A hard timeout on connection >duration, network access limitations, or (where appropriate) a limit on >the number of requests permitted on an anonymous connection may be >required to provide a minimal service guarantee in the face of malicious >access. I'm thinking the problem starts in paragraph 4 with the suggestion that servers should restrict the numbers of anonymous users. How about replacing both paragraph 4 and 5 with: If the anonymous user can run many expensive operations (e.g., an IMAP SEARCH BODY command), this could enable a denial of service attack. Servers are encouraged to reduce the priority of anonymous users or limit their resource usage. While servers may impose a limit on the number of anonymous users, it is noted that such a limit enables denial of service attacks and should be used with caution. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKA8j01474 for ietf-sasl-bks; Thu, 20 Feb 2003 12:10:08 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKA6d01470 for ; Thu, 20 Feb 2003 12:10:06 -0800 (PST) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id h1KKBUx02009; Thu, 20 Feb 2003 13:11:30 -0700 Message-ID: <3E553615.C2717C86@messagingdirect.com> Date: Thu, 20 Feb 2003 13:09:57 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Philip Guenther , ietf-sasl@imc.org Subject: Re: Unicode/UTF-8 issues (was: commentsondraft-ietf-sasl-anon-00) References: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> <5.2.0.9.0.20030220103201.01a11718@127.0.0.1> <5.2.0.9.0.20030220115255.026602a0@127.0.0.1> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" wrote: > Okay, how about I replace the grammar and the paragraph before > it as follows: This mostly works, see below. > A formal grammar for the client message using Augmented BNF [ABNF] > is provide below as a tool for understanding this technical > specification. > > message = [ email / token ] > ;; MUST be prepared in accordance with Section 2 > > UTF1 = %x00-3F / %x41-7F ;; less '@' (U+0040) > UTF2 = %xC2-DF UTF0 > UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / > %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) > UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / > %xF4 %x80-8F 2(UTF0) > UTF0 = %x80-BF > > TCHAR = UTF1 / UTF2 / UTF3 / UTF3 / UTF4 > ;; any UTF-8 encoded Unicode character > ;; except '@' (U+0040) Hmm, this suggests a typo in draft-yergeau-rfc2279bis-04.txt (UTF3 is shown twice). Also note, that this doesn't have UTF5 & UTF6 that you currently have: UTF5 = %xF8-FB 4(UTF0) UTF6 = %xFC-FD 5(UTF0) (but they have to be cleaned up to prevent overlong sequences). > email = addr-spec > ;; as defined in [IMAIL], except with no free > ;; insertion of linear-white-space, and the > ;; local-part MUST either be entirely enclosed in > ;; quotes or entirely unquoted > > token = 1*255TCHAR > > and add an appropriate acknowledgement. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KK8ah01404 for ietf-sasl-bks; Thu, 20 Feb 2003 12:08:36 -0800 (PST) Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KK8Zd01400 for ; Thu, 20 Feb 2003 12:08:35 -0800 (PST) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h1KK8aG24293; Thu, 20 Feb 2003 12:08:36 -0800 (PST) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.6/8.11.6) with ESMTP id h1KK9rV11903; Thu, 20 Feb 2003 12:09:53 -0800 (PST) Message-Id: <200302202009.h1KK9rV11903@katroo.Sendmail.COM> To: "Kurt D. Zeilenga" Cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: Unicode/UTF-8 issues (was: comments on draft-ietf-sasl-anon-00) In-reply-to: <5.2.0.9.0.20030220103201.01a11718@127.0.0.1> References: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> <5.2.0.9.0.20030220103201.01a11718@127.0.0.1> Date: Thu, 20 Feb 2003 11:56:34 -0800 From: Philip Guenther Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: ... >I gather that you are saying that ABNF is not precise enough. >(please correct me if I wrongly gathered). While I can >see that if you ignored all other text and the comments within >the ABNF, one could presume that the message, in hex, 0C 30 >was valid.... if one actually ignored all the other text >and the comments they could also presume that the invalid >messages 00 (in hex), foo"bar"@x (in ASCII), and many others >were valid. No, the latter is not valid by the grammar. My dislike for the current formulation is two-fold: TCHAR, as defined, isn't actually "any UTF-8 encoded Unicode character except '@' (U+0040)" as described in the comment. The UTF5 and UTF6 definitions do not match any legal UTF-8 character and the UTF3 and UTF4 definitions match illegal UTF-8 characters. I would prefer to find all the restrictions on what characters are legal in a token in a single location. The grammar could simply define TCHAR as a UTF-8 encoded character (perhaps using the productions in the draft Alexey mentioned) while the stringprep profile could handle all the restrictions on content at the level of Unicode characters. Yes, this makes the grammar ambiguous, but even rfc2822, the first 'target' for ABNF, has an amibiguous grammar that is only resolved by semantic restrictions in the general text. >Obviously, the grammar is not intended to be taken out of >context. It is provided as a tool for understanding the >text of the specification. As always, clarity and correctness are the goals. IMHO, defining a non-terminal that's neither a superset nor a subset of UTF-8, with additional restrictions elsewhere, makes it more difficult to understand. Philip Guenther Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KJukx01064 for ietf-sasl-bks; Thu, 20 Feb 2003 11:56:46 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KJuid01060 for ; Thu, 20 Feb 2003 11:56:44 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KJujxH030510; Thu, 20 Feb 2003 19:56:46 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220115255.026602a0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 11:55:11 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: Unicode/UTF-8 issues (was: comments ondraft-ietf-sasl-anon-00) Cc: Philip Guenther , ietf-sasl@imc.org In-Reply-To: <3E552A0A.AD59C02B@messagingdirect.com> References: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> <5.2.0.9.0.20030220103201.01a11718@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Okay, how about I replace the grammar and the paragraph before it as follows: A formal grammar for the client message using Augmented BNF [ABNF] is provide below as a tool for understanding this technical specification. message = [ email / token ] ;; MUST be prepared in accordance with Section 2 UTF1 = %x00-3F / %x41-7F ;; less '@' (U+0040) UTF2 = %xC2-DF UTF0 UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / %xF4 %x80-8F 2(UTF0) UTF0 = %x80-BF TCHAR = UTF1 / UTF2 / UTF3 / UTF3 / UTF4 ;; any UTF-8 encoded Unicode character ;; except '@' (U+0040) email = addr-spec ;; as defined in [IMAIL], except with no free ;; insertion of linear-white-space, and the ;; local-part MUST either be entirely enclosed in ;; quotes or entirely unquoted token = 1*255TCHAR and add an appropriate acknowledgement. Kurt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KJVtm29633 for ietf-sasl-bks; Thu, 20 Feb 2003 11:31:55 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KJVsd29629 for ; Thu, 20 Feb 2003 11:31:54 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KJVtxH030224; Thu, 20 Feb 2003 19:31:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220111223.02503718@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 11:30:21 -0800 To: Philip Guenther From: "Kurt D. Zeilenga" Subject: realms (Was: comments on draft-ietf-sasl-anon-00) Cc: ietf-sasl@imc.org In-Reply-To: <200302200807.h1K87JV13985@katroo.Sendmail.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:54 PM 2/19/2003, Philip Guenther wrote: >The ANONYMOUS mechanism does not provide a means for the client to >supply an optional realm in which the anonymous authentication should >take place. Correct, it doesn't. (The trace information has no semantical value.) >This makes the ANONYMOUS mechanism unusable by servers that >support multiple realms on a single communication end-point; it cannot >supplant the "anonymous@domain" login supported by, for example, some >IMAP servers. Maybe so. Are you asking for the WG to consider adding realm support to ANONYMOUS mechanism? Or asking the WG to consider clarifications to the ANONYMOUS mechanism that it is not applicable in scenarios allowing different anonymous associations to be established? Kurt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KJIsG29250 for ietf-sasl-bks; Thu, 20 Feb 2003 11:18:54 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KJIrd29246 for ; Thu, 20 Feb 2003 11:18:53 -0800 (PST) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id h1KJK8x01507; Thu, 20 Feb 2003 12:20:08 -0700 Message-ID: <3E552A0A.AD59C02B@messagingdirect.com> Date: Thu, 20 Feb 2003 12:18:34 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Philip Guenther , ietf-sasl@imc.org Subject: Re: Unicode/UTF-8 issues (was: comments ondraft-ietf-sasl-anon-00) References: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> <5.2.0.9.0.20030220103201.01a11718@127.0.0.1> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > >I believe Philip was referring to ABNF which allows for overlong UTF8 > >sequences. > > I gather that you are saying that ABNF is not precise enough. Correct. > (please correct me if I wrongly gathered). While I can > see that if you ignored all other text and the comments within > the ABNF, one could presume that the message, in hex, 0C 30 > was valid.... if one actually ignored all the other text > and the comments they could also presume that the invalid > messages 00 (in hex), foo"bar"@x (in ASCII), and many others > were valid. > > Obviously, the grammar is not intended to be taken out of > context. It is provided as a tool for understanding the > text of the specification. I've seen the version of the grammer that deals with overlong sequence. Check draft-yergeau-rfc2279bis-04.txt section 4. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KJAhn28968 for ietf-sasl-bks; Thu, 20 Feb 2003 11:10:43 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KJAfd28964 for ; Thu, 20 Feb 2003 11:10:41 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KJAfxH029810; Thu, 20 Feb 2003 19:10:42 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220103201.01a11718@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 11:09:07 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: Unicode/UTF-8 issues (was: comments on draft-ietf-sasl-anon-00) Cc: Philip Guenther , ietf-sasl@imc.org In-Reply-To: <3E551D7A.BFB50CE8@messagingdirect.com> References: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:24 AM 2/20/2003, Alexey Melnikov wrote: >"Kurt D. Zeilenga" wrote: > >> At 11:54 PM 2/19/2003, Philip Guenther wrote: >> >The syntax for UTF-8 characters in the draft permits "non-shortest form" >> >encodings >> >> I'm not exactly sure what you are referring to here. The >> draft says that the trace information is transferred as >> string of UTF-8 encoded Unicode characters. A non-shorted >> form UTF-8 encoding of a Unicode character is invalid per >> RFC 2247. I believe draft-yergeau-rfc2279bis-04.txt is >> more clear on this, so I'll change the reference. > >I believe Philip was referring to ABNF which allows for overlong UTF8 >sequences. I gather that you are saying that ABNF is not precise enough. (please correct me if I wrongly gathered). While I can see that if you ignored all other text and the comments within the ABNF, one could presume that the message, in hex, 0C 30 was valid.... if one actually ignored all the other text and the comments they could also presume that the invalid messages 00 (in hex), foo"bar"@x (in ASCII), and many others were valid. Obviously, the grammar is not intended to be taken out of context. It is provided as a tool for understanding the text of the specification. Kurt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KIP4i27542 for ietf-sasl-bks; Thu, 20 Feb 2003 10:25:04 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KIP2d27535 for ; Thu, 20 Feb 2003 10:25:02 -0800 (PST) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id h1KIQUx00882; Thu, 20 Feb 2003 11:26:30 -0700 Message-ID: <3E551D7A.BFB50CE8@messagingdirect.com> Date: Thu, 20 Feb 2003 11:24:58 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Philip Guenther , ietf-sasl@imc.org Subject: Re: Unicode/UTF-8 issues (was: comments on draft-ietf-sasl-anon-00) References: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" wrote: > At 11:54 PM 2/19/2003, Philip Guenther wrote: > >The syntax for UTF-8 characters in the draft permits "non-shortest form" > >encodings > > I'm not exactly sure what you are referring to here. The > draft says that the trace information is transferred as > string of UTF-8 encoded Unicode characters. A non-shorted > form UTF-8 encoding of a Unicode character is invalid per > RFC 2247. I believe draft-yergeau-rfc2279bis-04.txt is > more clear on this, so I'll change the reference. I believe Philip was referring to ABNF which allows for overlong UTF8 sequences. > If, however, you mean that the string of Unicode characters > is not normalized using an algorithm which produces the > minimum number of code points, yes. This is as intended. Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KI6Mc24981 for ietf-sasl-bks; Thu, 20 Feb 2003 10:06:22 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KI6Kd24969 for ; Thu, 20 Feb 2003 10:06:20 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KI69xH029409; Thu, 20 Feb 2003 18:06:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220092854.01a0bd18@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 10:04:34 -0800 To: Philip Guenther From: "Kurt D. Zeilenga" Subject: Unicode/UTF-8 issues (was: comments on draft-ietf-sasl-anon-00) Cc: ietf-sasl@imc.org In-Reply-To: <200302200807.h1K87JV13985@katroo.Sendmail.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:54 PM 2/19/2003, Philip Guenther wrote: >The syntax for UTF-8 characters in the draft permits "non-shortest form" >encodings I'm not exactly sure what you are referring to here. The draft says that the trace information is transferred as string of UTF-8 encoded Unicode characters. A non-shorted form UTF-8 encoding of a Unicode character is invalid per RFC 2247. I believe draft-yergeau-rfc2279bis-04.txt is more clear on this, so I'll change the reference. If, however, you mean that the string of Unicode characters is not normalized using an algorithm which produces the minimum number of code points, yes. This is as intended. >and encodings for characters outside the range of the Unicode >character set. Unassigned code points may be transferred. I will clarify that as I noted in another post. However, I believe the specification is clear that characters "outside the range", e.g. not in the repertoire of characters, are invalid. >Neither may be interpreted by a program conforming to >the Unicode 3.2 specification, which the draft references. Which is exactly why the specification restricts the string to a particular repertoire of characters. Kurt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KGkfB19262 for ietf-sasl-bks; Thu, 20 Feb 2003 08:46:41 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KGkdd19258 for ; Thu, 20 Feb 2003 08:46:40 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h1KGkYxH028616; Thu, 20 Feb 2003 16:46:35 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030220074940.01a10140@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 08:45:00 -0800 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: Last call for draft-ietf-sasl-anon-00 Cc: ietf-sasl@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 07:20 AM 2/20/2003, Simon Josefsson wrote: >The stringprep profile in section 2 is silent on unassigned code point >handling. Perhaps clarify that the list of unassigned code points is >empty, if that is indeed what is intended? I intended: The list of unassigned code points for this profile is that provided in appendix A of [RFC 3454]. Unassigned code points are not prohibited. Kurt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KFKDC15839 for ietf-sasl-bks; Thu, 20 Feb 2003 07:20:13 -0800 (PST) Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KFKBd15830 for ; Thu, 20 Feb 2003 07:20:12 -0800 (PST) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.7/8.12.7) with ESMTP id h1KFK4Xf023755 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Thu, 20 Feb 2003 16:20:07 +0100 To: ietf-sasl@imc.org Subject: Re: Last call for draft-ietf-sasl-anon-00 X-Payment: hashcash 1.1 0:030220:ietf-sasl@imc.org:414cfd3569157f27 X-Hashcash: 0:030220:ietf-sasl@imc.org:414cfd3569157f27 From: Simon Josefsson Date: Thu, 20 Feb 2003 16:20:04 +0100 In-Reply-To: (Sam Hartman's message of "Wed, 19 Feb 2003 15:13:18 -0500") Message-ID: User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/21.3.50 References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_GNUS_UA version=2.44 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The stringprep profile in section 2 is silent on unassigned code point handling. Perhaps clarify that the list of unassigned code points is empty, if that is indeed what is intended? ,---- RFC 3454 | The list of unassigned code points MUST be given in a profile, and | that list MUST be used by implementations of the profile. `---- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KCfxS05817 for ietf-sasl-bks; Thu, 20 Feb 2003 04:41:59 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KCfwd05813 for ; Thu, 20 Feb 2003 04:41:58 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09462; Thu, 20 Feb 2003 07:38:09 -0500 (EST) Message-Id: <200302201238.HAA09462@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2831bis-00.txt Date: Thu, 20 Feb 2003 07:38:08 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Using Digest Authentication as a SASL Mechanism Author(s) : P. Leach, C. Newman, A. Melnikov Filename : draft-ietf-sasl-rfc2831bis-00.txt Pages : 35 Date : 2003-2-19 This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2831bis-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2831bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-19142313.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2831bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19142313.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KCXq205583 for ietf-sasl-bks; Thu, 20 Feb 2003 04:33:52 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KCXpd05579 for ; Thu, 20 Feb 2003 04:33:51 -0800 (PST) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id h1KCZ8x29392; Thu, 20 Feb 2003 05:35:09 -0700 Message-ID: <3E54CB1B.8FACF46A@messagingdirect.com> Date: Thu, 20 Feb 2003 05:33:31 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Philip Guenther CC: ietf-sasl@imc.org Subject: Re: comments on draft-ietf-sasl-anon-00 References: <200302200807.h1K87JV13985@katroo.Sendmail.COM> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: > The ANONYMOUS mechanism does not provide a means for the client to > supply an optional realm in which the anonymous authentication should > take place. This makes the ANONYMOUS mechanism unusable by servers that > support multiple realms on a single communication end-point; See below. > it cannot supplant the "anonymous@domain" Which conforms to the syntax for "email", isn't it? > login supported by, for example, some IMAP servers. Server is not supposed to verify "email", so anything that looks like "email" just works fine. Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1K863G07744 for ietf-sasl-bks; Thu, 20 Feb 2003 00:06:03 -0800 (PST) Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1K862d07739 for ; Thu, 20 Feb 2003 00:06:02 -0800 (PST) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h1K861G17425 for ; Thu, 20 Feb 2003 00:06:01 -0800 (PST) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.6/8.11.6) with ESMTP id h1K87JV13985 for ; Thu, 20 Feb 2003 00:07:19 -0800 (PST) Message-Id: <200302200807.h1K87JV13985@katroo.Sendmail.COM> To: ietf-sasl@imc.org Subject: comments on draft-ietf-sasl-anon-00 Date: Wed, 19 Feb 2003 23:54:04 -0800 From: Philip Guenther Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The syntax for UTF-8 characters in the draft permits "non-shortest form" encodings and encodings for characters outside the range of the Unicode character set. Neither may be interpreted by a program conforming to the Unicode 3.2 specification, which the draft references. Paragraph 5 of section 4 (security consideration), suggests the use of an idle timeout on servers that place a limit on the number of concurrent anonymous users in order to combat a denial-of-service attack. As keeping a connection from being considered idle will generally require simply sending a request (possibly even a malformed request), it's unlikely that an idle timeout will actually prevent an intentional DOS attack from succeeding. A hard timeout on connection duration, network access limitations, or (where appropriate) a limit on the number of requests permitted on an anonymous connection may be required to provide a minimal service guarantee in the face of malicious access. The ANONYMOUS mechanism does not provide a means for the client to supply an optional realm in which the anonymous authentication should take place. This makes the ANONYMOUS mechanism unusable by servers that support multiple realms on a single communication end-point; it cannot supplant the "anonymous@domain" login supported by, for example, some IMAP servers. Philip Guenther Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1JKDIT07214 for ietf-sasl-bks; Wed, 19 Feb 2003 12:13:18 -0800 (PST) Received: from konishi-polis.mit.edu (STRATTON-FOUR-THIRTY-FOUR.MIT.EDU [18.187.6.179]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1JKDHd07209 for ; Wed, 19 Feb 2003 12:13:17 -0800 (PST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id B64EF151F11; Wed, 19 Feb 2003 15:13:18 -0500 (EST) To: ietf-sasl@imc.org Subject: Last call for draft-ietf-sasl-anon-00 From: Sam Hartman Date: Wed, 19 Feb 2003 15:13:18 -0500 Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message initiates a SASL Working Group Last Call on the document: Title : The Anonymous SASL Mechanism Editor : K. Zeilenga Filename : draft-ietf-sasl-anon-00.txt The purpose of this WG Last Call is to ensure that the Working Group has achieved consensus that the document is suitable for publication as a Proposed Standard. Please review the document for both technical and editorial problems. Technical issues should be discussed on this list. Editorial issues may be sent to the document editor. The Last Call period will end on Wednesday, March 5, 2003. Upon completion of the last call, the WG chair(s) will take action based upon the consensus of the WG. Possible actions include: 1) recommending to the IETF Security Area Directors that the document, after possible editorial or other minor changes, be considered by the IESG for publication as a Standard Track RFC (which generally involves an IETF-wide Last Call); or 2) requiring that outstanding issues be adequately addressed prior to further action (including, possibly, another WG Last Call). Remember that it is our responsibility as Working Group members to ensure the quality of our documents and of the Internet Standards process. So, please read and comment! - Sam Hartman SASL co-chair Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1BBoBT13831 for ietf-sasl-bks; Tue, 11 Feb 2003 03:50:11 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BBoAd13827 for ; Tue, 11 Feb 2003 03:50:10 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28775; Tue, 11 Feb 2003 06:46:27 -0500 (EST) Message-Id: <200302111146.GAA28775@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-plain-00.txt Date: Tue, 11 Feb 2003 06:46:27 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The Plain SASL Mechanism Author(s) : K. Zeilenga Filename : draft-ietf-sasl-plain-00.txt Pages : 8 Date : 2003-2-10 This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols which lack a simple password authentication command. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-plain-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-plain-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-plain-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-10135953.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-plain-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-plain-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-10135953.I-D@ietf.org> --OtherAccess-- --NextPart--