From owner-ietf-sasl Thu Jun 3 10:20:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53HKv8H003905; Thu, 3 Jun 2004 10:20:57 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i53HKvt4003904; Thu, 3 Jun 2004 10:20:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fe.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53HKu5f003880; Thu, 3 Jun 2004 10:20:56 -0700 (PDT) (envelope-from paulr@rcom-software.com) Received: from [64.139.27.223] (HELO rcom-software.com) by fe.mail.megapathdsl.net (CommuniGate Pro SMTP 4.1.8) with ESMTP id 172482636; Thu, 03 Jun 2004 10:20:54 -0700 Message-ID: <40BF5E34.97B4473B@rcom-software.com> Date: Thu, 03 Jun 2004 10:21:56 -0700 From: Paul Romero Organization: RCOM Communications Software X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en,es,de-DE,fr-FR MIME-Version: 1.0 To: ietf-sasl@imc.org, phoffman@imc.org Subject: Use of AUTH with SMTP 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: Dear SASL User Group Can anybody provide some insight into the following questions about how the AUTH mechanism is used with SMTP ? 1) How commonly deployed is the AUTH mechanism--as described in RFC 2554--in commercial ISP SMTP implementations ? 2) Is the CRAM-MD5 variant normally used ? If not, which others are commonly used ? 3) Is the AUTH mechanism usually implemented on a stand alone basis or in conjunction with other service--for instance TLS ? 3.1) If it is implemented with other services, what are the relevant RFCs ? Best Regards, Paul Romero -- Paul Romero RCOM Communications Software Phone/Fax: (510)339-2628 E-Mail: paulr@rcom-software.com From owner-ietf-sasl Fri Jun 4 08:56:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54FuGp8037722; Fri, 4 Jun 2004 08:56:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i54FuGAF037721; Fri, 4 Jun 2004 08:56:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54FuE5X037710 for ; Fri, 4 Jun 2004 08:56:14 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i54Fswqf045171; Fri, 4 Jun 2004 15:55:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040603232331.049a3188@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 04 Jun 2004 08:54:54 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: Use of NFKC in SASLprep Cc: ietf-sasl@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i54FuF5X037716 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 04:19 PM 4/22/2004, Simon Josefsson wrote: >FYI, as SASLprep is using NFKC per Unicode 3.2, you might be >interested in the NFKC stability problem discussed on >. The page mention a >strategy to maintain stability across NFKC revisions, which might be >relevant for SASLPrep. I'd be interested to hear people's opinions on >the problem. I recently consulted with authors of [Stringprep] (namely Paul Hoffman) as well as our liaison to the UTC (Patrik Fältström) regarding this [SASLprep] concern. They recommend that the SASLprep I-D not attempt to fix the issue discussed in PR#29. They argue (as I understand their arguments) that it would be inappropriate for SASLprep, a profile of Stringprep, to apply PR#29 to a version of Unicode instead of utilize Unicode normalization as required by Stringprep. Or, to say it in another way, PR#29 issues in a consistent manner for all profiles of Stringprep and hence ought to be handled as part of the ongoing revision of Stringprep (and its normative references). They suggest we not wait for this revision. I fully support with their recommendation (which is consistent with my prior recommendations to the WG). We also had a discussion as to wether the SASLprep I-D should note the existence of this issue (without any fix) and its impact upon implementations (and use) of SASLprep. They argued that such would be inappropriate for SASLprep I-D to include such as there no issue specific to the SASLprep profile of Stringprep here. They noted it **might** be appropriate to publish an Informational RFC updating [Stringprep]. While I have some mild reservations, I can support this recommendation. Please consider these recommendations. Sam (as chair) and I (as editor) intend to response to the IESG comment regarding concern within the next week. Kurt From owner-ietf-sasl Sat Jun 5 05:20:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i55CK2u5088727; Sat, 5 Jun 2004 05:20:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i55CK2Y7088726; Sat, 5 Jun 2004 05:20:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i55CJvWM088704 for ; Sat, 5 Jun 2004 05:19:58 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BWa9U-00048X-00 for ; Sat, 05 Jun 2004 14:19:56 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 05 Jun 2004 14:19:56 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 05 Jun 2004 14:19:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Use of NFKC in SASLprep Date: Sat, 05 Jun 2004 14:19:48 +0200 Lines: 70 Message-ID: References: <6.0.1.1.0.20040603232331.049a3188@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:/eeEHBfvkEPyendj6K8TeUuxiQQ= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > We also had a discussion as to wether the SASLprep I-D should > note the existence of this issue (without any fix) and its > impact upon implementations (and use) of SASLprep. They argued > that such would be inappropriate for SASLprep I-D to include > such as there no issue specific to the SASLprep profile of > Stringprep here. So, what do we have here? There is a known specification ambiguity in NFKC that, for example, appear to allow implementations to return three distinct output from the input string U+0B47 U+0300 U+0B3E U+0323 (see earlier discussion). This is an interoperability problem. It appears to make SASLPrep2 more complicated to specify (since SASLprep is not idempotent), with consequences for SASL user database migration (if prepared strings are stored in the database, which I have suggested shouldn't be the case in another thread). It is difficult to see that this property is impossible to abuse when attacking systems that use SASLprep on authentication/authorization tokens. And the conclusion? Let's ignore the issue, and make sure it is not even mentioned. Speaking as an implementor, I hesitate to expose my users to this issue. The conservative approach appear to be to enforce, in the implementation, a local policy of rejecting the ambiguous input strings directly. This remove the need to worry about this issue, without any obvious negative consequences (correct me if I'm wrong). Applying the same conservative approach to the specification seem possible. The drawback of doing so? We have to describe how implementions should detect and reject the ambiguous combination of code points. The advantage? Implementors aren't exposed to interoperability and security issues. Further, migrating to SASLprep2 may be simpler since it is more likely to be able to assume SASLprep is idempotent. Below is a proposal for this section, and I hope it can be considered. If the text, or something similar to it, is not adopted, I feel that at least acknowledging the issue would be appropriate. The ambiguity in NFKC doesn't disappear even if you refuse to acknowledge it. What do other implementors think? Have you compared the NFKC implementation you use with the test vectors in PR-29? Thanks, Simon 2.3.1 Prohibited Output Of Problem Sequences The algorithm used by [StringPrep] to normalize sequences have been discovered [PR-29] to be non-idempotent. Fortunately, this appear to only affect a restricted set of combination of code points, and none of those combinations are believed to occur naturally (due to different linguistic uses of the characters). Idempotency of the SASLprep operation is important for interoperability, security, and migration to revised versions of SASLprep. Thus, this section prohibit the problem sequences from occurring in SASLprep output. The logic to detect and prohibit the problem sequences uses the tables from [PR-29]. The problem sequences begin with a code point from one row in column 1 of table 1, followed by one or more of the 163 code points with a non-zero Canonical Combination Class (see Table 2), followed by one of the code points in the same row, in column 2 of Table, corresponding to the row of the first code point. [Table 1 is table 2 from .] [Table 2 is the non-zero entries of ] From owner-ietf-sasl Sat Jun 5 17:40:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i560eD5X076741; Sat, 5 Jun 2004 17:40:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i560eDto076739; Sat, 5 Jun 2004 17:40:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mariner.pc.cs.cmu.edu (dsl093-061-085.pit1.dsl.speakeasy.net [66.93.61.85]) by above.proper.com (8.12.11/8.12.9) with SMTP id i560eAwx076729 for ; Sat, 5 Jun 2004 17:40:10 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa31514; 5 Jun 2004 20:39 EDT Date: Sat, 05 Jun 2004 20:39:46 -0400 From: Jeffrey Hutzelman To: Simon Josefsson , ietf-sasl@imc.org Subject: Re: Use of NFKC in SASLprep Message-ID: <40110000.1086482386@mariner.pc.cs.cmu.edu> In-Reply-To: References: <6.0.1.1.0.20040603232331.049a3188@127.0.0.1> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Saturday, June 05, 2004 14:19:48 +0200 Simon Josefsson wrote: > So, what do we have here? There is a known specification ambiguity in > NFKC that, for example, appear to allow implementations to return > three distinct output from the input string U+0B47 U+0300 U+0B3E > U+0323 (see earlier discussion). This is an interoperability problem. > It appears to make SASLPrep2 more complicated to specify (since > SASLprep is not idempotent), with consequences for SASL user database > migration (if prepared strings are stored in the database, which I > have suggested shouldn't be the case in another thread). It is > difficult to see that this property is impossible to abuse when > attacking systems that use SASLprep on authentication/authorization > tokens. And the conclusion? Let's ignore the issue, and make sure it > is not even mentioned. It strikes me that people are blowing this way out of proportion, and I really dislike the repeated attempts in this working group to "fix" Unicode, which is _way way way_ out of scope for us. There is not a problem with NFKC. There is a TYPO in the document which specifies it. If NFKC is implemented correctly, as is done by multiple implementations _including the sample implementation in the same document_, there is no problem. This is not the end of the world. We've certainly had similar problems in IETF documents; the RFC Editor has a long list of errata for published RFC's. I cannot imagine that the Unicode Consortium will not publish a corrigendum to correct the erroneous document. In the meantime, because SASLprep will be used in security-sensitive applications including SASL and Kerberos, I think it is appropriate to include a reference to PR-29 and a recommendation that implementors insure that NFKC is implemented correctly. I do _not_ think it is appropriate to suggest behaviour _other_ than simply implementing NFKC correctly. For example, I don't think it's appropriate to specify that a large class of sequences be prohibited from output. Any implementation which would be in a position to implement such a suggestion is _also_ in a position to get NFKC right in the first place, thereby avoiding the entire problem. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From owner-ietf-sasl Sun Jun 6 03:20:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i56AKCsk032750; Sun, 6 Jun 2004 03:20:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i56AKCWH032749; Sun, 6 Jun 2004 03:20:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i56AK7up032741 for ; Sun, 6 Jun 2004 03:20:08 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BWul6-0000M3-00 for ; Sun, 06 Jun 2004 12:20:08 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 06 Jun 2004 12:20:08 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 06 Jun 2004 12:20:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Use of NFKC in SASLprep Date: Sun, 06 Jun 2004 12:20:03 +0200 Lines: 25 Message-ID: References: <6.0.1.1.0.20040603232331.049a3188@127.0.0.1> <40110000.1086482386@mariner.pc.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:RZeeepijxtJ6QM25COpKhxxPWz4= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman writes: > There is not a problem with NFKC. There is a TYPO in the document > which specifies it. If NFKC is implemented correctly, as is done by > multiple implementations _including the sample implementation in the > same document_, there is no problem. I spoke to other implementors of StringPrep, which do implement NFKC the same way as the reference implementation (i.e., not according to the letter of the specification), and one of the Stringprep authors had told them that then they were simply not following the current specifications. I think a public statement committing to one of the two interpretation (i.e., either consider it a typo in the old version of NFKC, or that the typo corrected NFKC will be a new version, which StringPrep doesn't use yet) of this problem would be useful. > In the meantime, because SASLprep will be used in security-sensitive > applications including SASL and Kerberos, I think it is appropriate to > include a reference to PR-29 and a recommendation that implementors > insure that NFKC is implemented correctly. We agree about this. Thanks, Simon From owner-ietf-sasl Mon Jun 7 14:45:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i57LjKvM005557; Mon, 7 Jun 2004 14:45:20 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i57LjKwV005556; Mon, 7 Jun 2004 14:45:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i57LjJ7O005549 for ; Mon, 7 Jun 2004 14:45:19 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 32057151F18; Mon, 7 Jun 2004 17:45:23 -0400 (EDT) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: Use of NFKC in SASLprep References: <6.0.1.1.0.20040603232331.049a3188@127.0.0.1> From: Sam Hartman Date: Mon, 07 Jun 2004 17:45:23 -0400 In-Reply-To: (Simon Josefsson's message of "Sat, 05 Jun 2004 14:19:48 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) 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: >>>>> "Simon" == Simon Josefsson writes: Simon> appears to make SASLPrep2 more complicated to specify Simon> (since SASLprep is not idempotent), with consequences for Simon> SASL user database migration (if prepared strings are Simon> stored in the database, which I have suggested shouldn't be Simon> the case in another thread). As someone who tends to believe that prepared strings should be stored in the database, I think it is worth working through the issues of what we will do with saslprep2 now. My presumption is that we go forward assuming that saslprep is idempotent even though we know it is not. That is, we ignore this issue now and for all future versions of saslprep. --Sam From owner-ietf-sasl Fri Jun 18 13:18:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IKITKF067550; Fri, 18 Jun 2004 13:18:29 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5IKITeB067549; Fri, 18 Jun 2004 13:18:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fe.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IKISZd067536 for ; Fri, 18 Jun 2004 13:18:28 -0700 (PDT) (envelope-from paulr@rcom-software.com) Received: from [64.139.27.223] (HELO rcom-software.com) by fe.mail.megapathdsl.net (CommuniGate Pro SMTP 4.1.8) with ESMTP id 157475961; Fri, 18 Jun 2004 13:18:27 -0700 Message-ID: <40D34E54.9C380C49@rcom-software.com> Date: Fri, 18 Jun 2004 13:19:32 -0700 From: Paul Romero Organization: RCOM Communications Software X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en,es,de-DE,fr-FR MIME-Version: 1.0 To: libesmtpd-devel@community.uklinux.net CC: ietf-sasl@imc.org Subject: LIBESMTPD: E-Mail Client on UC Linux ? 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: Dear Brian and LIBESMTP Aficionados: I downloaded the Debian version of the libesmtp source code and can now send E-mail with the sample program--provided with libesmtp-dev, under the following conditions. (i.e. My system does not provide an SMTP server.) The Linux "inetd" has established an Internet connection, TCP port number 25 is used, and the host--as specified with "-h"-- identifies a system that provides SMTP service. (i.e. I used symbolic names for the mail servers.) Some seemingly important modifications were required which are detailed below--as well as the other significant factors. My system runs Linux "inetd" over an Ethernet card, but I suspect this would work with a modem connection once the IP/PPP to ISP connection is established with cooperation from Linux "pppd" and "inetd". Also, I did not actually try the AUTH capability. I plan to use my SMTP software to connect directly to SMTP servers--without additional forwarding or queuing software--and would like more insight into the following general issues: (i.e. My application is an MTA only between the PC and the ISP SMTP Server--virtually an MUA.) * Is the libesmtp package described on the website significantly different than the Linux version--libesmtp5 and libesmtp-dev ? * Does libesmtp provide DIGEST-MD5 and GSS API-Kerberos authentication as well as CRAM-MD5 ? If not, what are the future plans in this respect ? * Is libesmpt robust enough to handle direct connections to SMTP servers--via TCP/IP ? (i.e. Not on my local system.) * Has libesmtp been ported to UC Linux or would you recommend doing so ? (i.e. Memory space is quite limited.) * Do you know of US ISPs that would allow low cost experimentation with the AUTH mechanism ? * What part of the documentation describes how to configure the "secret" etc. as used by the CRAM-MD5 variant of AUTH ? * Would it be difficult to modify the libesmtp to facilitate the transmission of streaming E-mail ? (i.e. Multiple user data writes after a positive 354 response to the SMTP DATA command instead of retrieving data from a file.) If you feel that libesmtpd is not appropriate for the environment I described, can you recommend another software package ? Finally, the details I mentioned earlier follow. Best Regards, Paul Romero MODIFICATIONS The libesmtp-dev software had to be recompiled and reinstalled with the following modifications before E-mail could be sent. had to be set up for a UDP Datagram socket. * The sample program was modified pass both the host name and TCP port number 25 to the lower level software. * Before calling getaddrinfo() the parameters had to be set up for a UDP Datagram socket. (i.e. In protocol.c) The relevant parameters-- mostly in the "hints" structure are as follows: . Protocol Family: PF_INET . Socket Type: SOCK_DGRAM . Protocol: IPPROTO_UDP . Flags: AI_CANONNAME (i.e. ai_canonname set to the host name which is also passed as an argument to getaddrinfo().) Notes: The exact details are particular to Debian but, I suspect they don't vary much on most versions of Linux. Also, there is only 1 getaddrinfo() call in the whole file. * The socket() call to establish a connection had to be modified to setup up a TCP streaming socket. (i.e. In protocol.c) The socket() arguments are as follows: . domain: PF_INET . type: SOCK_STREAM . protocols: 0 (i.e. Mandatory for Debian.) Note: There is only 1 getaddrinfo() call in the same file, and I think this will work for all versions of Linux. SMTP SOFTWARE * Standard Debian Version of libesmtp5--version 0.8--and libesmtp-dev--Version 8.11--packages. (i.e. Downloaded these from the Debian website.) PROTOCOL SETUP * Standard Linux & Socket TCP/IP tools. * IP over LLC2 (i.e. via conventional Linux "inetd") * Ethernet Card attached to PC Bus and connected to Netopia DSL router. * DSL router uses ADSL and exchanges date via ATM with the DSLAM at the CO. HARDWARE ENVIRONMENT * Normal Intel Based PC * Ethernet Card * Netopia DSL Router OS * Stock distribute of "Woody" Debian Linux. (i.e. Release 2.2.17 ) -- Paul Romero RCOM Communications Software Phone/Fax: (510)339-2628 E-Mail: paulr@rcom-software.com From owner-ietf-sasl Fri Jun 18 14:05:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IL5hos072283; Fri, 18 Jun 2004 14:05:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5IL5hct072282; Fri, 18 Jun 2004 14:05:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fe.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IL5gJO072258 for ; Fri, 18 Jun 2004 14:05:42 -0700 (PDT) (envelope-from paulr@rcom-software.com) Received: from [64.139.27.223] (HELO rcom-software.com) by fe.mail.megapathdsl.net (CommuniGate Pro SMTP 4.1.8) with ESMTP id 177133214; Fri, 18 Jun 2004 14:05:41 -0700 Message-ID: <40D35966.C74DA943@rcom-software.com> Date: Fri, 18 Jun 2004 14:06:46 -0700 From: Paul Romero Organization: RCOM Communications Software X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en,es,de-DE,fr-FR MIME-Version: 1.0 To: ietf-sasl@imc.org, uclinux-dev@uclinux.org CC: hroskos@cermetek.com, email@joernweber.de, mel@isode.com Subject: SMTP/AUTH Software Recommendation 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: Hi Folks: Could you recommend a stand alone SMTP CLIENT software package that satisfies the following criteria ? * It provides the following AUTH mechanisms in order of importance: CRAM-MD5, DIGEST-MD5, and GSS API-Kerberos. (i.e. Don't really need TLS.) * Has an API accessible via C subroutine calls. * Is independent of TCP/IP connection media-- modem, ethernet etc. * Uses a relatively small amount of memory. * Runs on Linux in user space using only standard Linux tools and socket calls, and relies only on Linux "inetd" and "pppd". * Sends E-mail directly to SMTP servers without local queuing or additional MTAs. * Is ported or can easily be ported to UC Linux. * Can accept multiple user data API writes after a successful 354 response to the SMTP DATA command. (i.e. Streaming E-mail.) Any comments or insight would be appreciated. Best Regards, Paul R. -- Paul Romero RCOM Communications Software Phone/Fax: (510)339-2628 E-Mail: paulr@rcom-software.com From owner-ietf-sasl Mon Jun 21 16:27:37 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LNRbgv094519; Mon, 21 Jun 2004 16:27:37 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LNRbBK094518; Mon, 21 Jun 2004 16:27:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LNRXY4094437 for ; Mon, 21 Jun 2004 16:27:35 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust180.tnt24.lnd4.gbr.da.uu.net [62.188.151.180]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 22 Jun 2004 00:28:03 +0100 Message-ID: <40D7666B.7070001@isode.com> Date: Mon, 21 Jun 2004 23:51:23 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: SASL WG Subject: Final changes to the base SASL document References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: >On Fri, 21 May 2004, Sam Hartman wrote: > > >> >> It seems we can handle this cleanly enough if we treat it just >> >> like the initial response. >> >>But is it worth the complexity? IT seems that if we can avoid the >>introduction of distinguishing the two cases we should do so. >> >> > >If it is not worth the complexity (and, really, I can't think of any >situation where an empty server success data would be *useful*-- it just >seems that we'd be giving up some level of flexibility), then we should >just forbid empty success data -- this would lead to the less confusion >than attributing two potential meanings to "no success data". > > Should I treat "forbid empty success data" as the WG consensus on empty versa no data on success? I would like to publish [the last] revision of the base SASL spec. Alexey From owner-ietf-sasl Mon Jun 21 16:28:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LNSgna094758; Mon, 21 Jun 2004 16:28:42 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LNSg8L094757; Mon, 21 Jun 2004 16:28:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LNSe5E094743 for ; Mon, 21 Jun 2004 16:28:41 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust180.tnt24.lnd4.gbr.da.uu.net [62.188.151.180]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 22 Jun 2004 00:28:48 +0100 Message-ID: <40D76891.4030703@isode.com> Date: Tue, 22 Jun 2004 00:00:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Ken Murchison CC: "Kurt D. Zeilenga" , Rob Siemborski , SASL WG Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> <6.0.1.1.0.20040521094503.0483fe28@127.0.0.1> <6.0.1.1.0.20040521103442.049371d8@127.0.0.1> <6.0.1.1.0.20040521105853.0483ca98@127.0.0.1> <6.0.1.1.0.20040521111921.0493f458@127.0.0.1> <6.0.1.1.0.20040521114345.02cb9138@127.0.0.1> <40AE6276.4010706@oceana.com> <40AE68CC.9030900@oceana.com> In-Reply-To: <40AE68CC.9030900@oceana.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison wrote: > Ken Murchison wrote: > >> Kurt D. Zeilenga wrote: >> >>> At 11:41 AM 5/21/2004, Rob Siemborski wrote: >>> >>>> It also states: >>>> >>>> 7.4. External mechanism >>>> The client sends an initial response with the authorization identity. >>> >>> Note that it does not say: >>> The client may optionally send an initial response with the >>> authorization >>> identity. >>> >>> And, if the client were not to send an initial response, there is no >>> specified challenge for the server to issue to obtain the authorization >>> identity. >> >> I think the problem here is that the EXTERNAL spec uses the term >> "initial response" which is implying that the response can only be >> sent with the command which starts the authentication. My >> understanding is that EXTERNAL consists of a single message sent from >> client to server which contains the authzid. If the protocol profile >> allows for an initial response and the client chooses to do so, then >> the authzid MAY be sent as an initial response. Otherwise, the >> server will send an empty challenge to prompt the client for the >> authzid. Either way, the client MUST provide an authzid. > > > I should have added the following to my last sentence: "which may be > empty". I've changed the paragraph to be: The client sends a single message containing the UTF-8 encoding of the authorization identity. The message may be empty. The form of the authorization identity is further restricted by the application-level protocol's SASL profile. Alexey From owner-ietf-sasl Thu Jun 24 10:35:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OHZQ3i078059; Thu, 24 Jun 2004 10:35:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OHZQbK078058; Thu, 24 Jun 2004 10:35:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fe.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OHZQc6078051 for ; Thu, 24 Jun 2004 10:35:26 -0700 (PDT) (envelope-from paulr@rcom-software.com) Received: from [64.139.27.223] (HELO rcom-software.com) by fe.mail.megapathdsl.net (CommuniGate Pro SMTP 4.1.8) with ESMTP id 178852070 for ietf-sasl@imc.org; Thu, 24 Jun 2004 10:35:24 -0700 Message-ID: <40DB111C.315EB785@rcom-software.com> Date: Thu, 24 Jun 2004 10:36:28 -0700 From: Paul Romero Organization: RCOM Communications Software X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en,es,de-DE,fr-FR MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Validation of SASL/AUTH Features 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: Dear SASL Group: I need to perform some experiments with AUTH functionality. Can anybody recommend ISPs which operate in Northern California and offer a variety of AUTH features. My particular interest is CRAM-MD5 without a dial up connection. Best Regards, Paul R. -- Paul Romero RCOM Communications Software Phone/Fax: (510)339-2628 E-Mail: paulr@rcom-software.com From owner-ietf-sasl Thu Jun 24 21:02:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P42ct6033953; Thu, 24 Jun 2004 21:02:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P42cWC033952; Thu, 24 Jun 2004 21:02:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P42ccV033944 for ; Thu, 24 Jun 2004 21:02:38 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i5P42gMC017880 for ; Fri, 25 Jun 2004 04:02:42 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040624205012.04833890@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 24 Jun 2004 21:02:47 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Re: Use of NFKC in SASLprep In-Reply-To: References: <6.0.1.1.0.20040603232331.049a3188@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 02:45 PM 6/7/2004, Sam Hartman wrote: >My presumption is that we go forward assuming that saslprep is >idempotent even though we know it is not. That is, we ignore this >issue now and for all future versions of saslprep. I have written the following text, replacing the first paragraph of the Security Consideration discussion, to make note of the issue. This profile is intended to used to prepare simple user names and passwords strings for comparison or use in cryptographic functions (e.g., message digests). The preparation algorithm was specifically designed such that its output is canonical, and it is for well-formed. However, due to an anomaly [PR29] in specification of Unicode normalization, canonical equivalence is not guaranteed for a select few character sequences. These sequences, however, do not appear in well-formed text. This specification was published despite this known technical problem. It is expected that this specification will be revised before further progression on the Standards Track (after [Unicode] and/or [StringPrep] specifications have been updated to address this problem). Comments? Alternative wording? Kurt From owner-ietf-sasl Fri Jun 25 03:38:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PAc4wZ059335; Fri, 25 Jun 2004 03:38:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PAc4P3059334; Fri, 25 Jun 2004 03:38:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PAc0EQ059326 for ; Fri, 25 Jun 2004 03:38:01 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Bdo5i-00023Z-00 for ; Fri, 25 Jun 2004 12:37:54 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Jun 2004 12:37:54 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Jun 2004 12:37:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Use of NFKC in SASLprep Date: Fri, 25 Jun 2004 12:37:49 +0200 Lines: 34 Message-ID: References: <6.0.1.1.0.20040603232331.049a3188@127.0.0.1> <6.0.1.1.0.20040624205012.04833890@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:0DFje/vO2qsGqLW6ur2X7TenZvI= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > At 02:45 PM 6/7/2004, Sam Hartman wrote: >>My presumption is that we go forward assuming that saslprep is >>idempotent even though we know it is not. That is, we ignore this >>issue now and for all future versions of saslprep. > > I have written the following text, replacing the first paragraph > of the Security Consideration discussion, to make note of the > issue. > > This profile is intended to used to prepare simple user names and > passwords strings for comparison or use in cryptographic functions > (e.g., message digests). The preparation algorithm was specifically > designed such that its output is canonical, and it is for well-formed. ^^^^^^^^^^^^^^^^^^^^^^^^^^ I have trouble parsing the last part? > However, due to an anomaly [PR29] in specification of Unicode > normalization, canonical equivalence is not guaranteed for a select > few character sequences. These sequences, however, do not appear > in well-formed text. This specification was published despite > this known technical problem. It is expected that this specification > will be revised before further progression on the Standards Track > (after [Unicode] and/or [StringPrep] specifications have been updated > to address this problem). > > Comments? Alternative wording? Otherwise it looks fine to me! Thanks, Simon From owner-ietf-sasl Fri Jun 25 08:31:21 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PFVKWr085412; Fri, 25 Jun 2004 08:31:21 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PFVKhr085411; Fri, 25 Jun 2004 08:31:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PFVJm0085403 for ; Fri, 25 Jun 2004 08:31:19 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i5PFUBMC023379; Fri, 25 Jun 2004 15:30:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040625082919.04bb84c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 25 Jun 2004 08:30:15 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: Use of NFKC in SASLprep Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040603232331.049a3188@127.0.0.1> <6.0.1.1.0.20040624205012.04833890@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 03:37 AM 6/25/2004, Simon Josefsson wrote: >>and it is for well-formed. > ^^^^^^^^^^^^^^^^^^^^^^^^^^ >I have trouble parsing the last part? s/well-formed/well-formed text/ Kurt From owner-ietf-sasl Fri Jun 25 10:34:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PHYGPr094668; Fri, 25 Jun 2004 10:34:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PHYGWP094667; Fri, 25 Jun 2004 10:34:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PHYGGp094661 for ; Fri, 25 Jun 2004 10:34:16 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i5PHYJMC024386 for ; Fri, 25 Jun 2004 17:34:19 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040625103414.04bd6ad8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 25 Jun 2004 10:34:23 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: bounces when posting to this list 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: I recently noticed that mail to one of the list subscribers was being bounced back to poster (instead of to the list owner... or not at all) asking the post to click on some URL. I've sent a note to this subscriber to fix their problem and intend to remove the subscriber if their problem is not soon corrected. If you noticed such problems, you should feel free to complain to chairs and/or . Kurt SASL co-chair From owner-ietf-sasl Mon Jun 28 12:35:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SJZKfC005795; Mon, 28 Jun 2004 12:35:20 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5SJZKo9005794; Mon, 28 Jun 2004 12:35:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SJZJaw005781 for ; Mon, 28 Jun 2004 12:35:19 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25861; Mon, 28 Jun 2004 15:35:21 -0400 (EDT) Message-Id: <200406281935.PAA25861@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-gssapi-01.txt Date: Mon, 28 Jun 2004 15:35:21 -0400 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 : SASL GSSAPI mechanisms Author(s) : A. Melnikov Filename : draft-ietf-sasl-gssapi-01.txt Pages : 15 Date : 2004-6-28 The Simple Authentication and Security Layer [SASL] is a method for adding authentication support to connection-based protocols. This document describes the method for using the Generic Security Service Application Program Interface [GSSAPI] in the Simple Authentication and Security Layer [SASL]. This document replaces section 7.2 of RFC 2222 [SASL], the definition of the 'GSSAPI' SASL mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-gssapi-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-gssapi-01.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-gssapi-01.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: <2004-6-28151329.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-gssapi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-gssapi-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-28151329.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Tue Jun 29 12:29:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TJTDUO017875; Tue, 29 Jun 2004 12:29:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TJTD1P017874; Tue, 29 Jun 2004 12:29:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TJTCa9017867 for ; Tue, 29 Jun 2004 12:29:12 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11485; Tue, 29 Jun 2004 15:29:15 -0400 (EDT) Message-Id: <200406291929.PAA11485@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-08.txt Date: Tue, 29 Jun 2004 15:29:15 -0400 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 : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-08.txt Pages : 11 Date : 2004-6-29 The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-based protocols. It also describes a structure for authentication mechanisms. The result is an abstraction layer between protocols and authentication mechanisms such that any SASL- compatible authentication mechanism can be used with any SASL- compatible protocol. This document describes how a SASL authentication mechanism is structured, describes how a protocol adds support for SASL, defines the protocol for carrying a security layer over a connection, and defines the SASL EXTERNAL authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rfc2222bis-08.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-rfc2222bis-08.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: <2004-6-29150243.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-29150243.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Wed Jun 30 02:51:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U9psP4074146; Wed, 30 Jun 2004 02:51:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5U9psuA074145; Wed, 30 Jun 2004 02:51:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U9pq6s074135 for ; Wed, 30 Jun 2004 02:51:53 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 30 Jun 2004 10:53:02 +0100 Message-ID: <40E1381F.4020409@isode.com> Date: Tue, 29 Jun 2004 10:36:31 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: SASL WG Subject: New revision of draft-ietf-sasl-gssapi References: <40DC9563.4070006@isode.com> In-Reply-To: <40DC9563.4070006@isode.com> 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: Version 00 has expired recently. I've submitted -01 which was announced today. Only minor tweaks in this version: updated Copyright, clarified that authorization id is in UTF-8. Alexey From owner-ietf-sasl Thu Jun 3 10:20:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53HKv8H003905; Thu, 3 Jun 2004 10:20:57 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i53HKvt4003904; Thu, 3 Jun 2004 10:20:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fe.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53HKu5f003880; Thu, 3 Jun 2004 10:20:56 -0700 (PDT) (envelope-from paulr@rcom-software.com) Received: from [64.139.27.223] (HELO rcom-software.com) by fe.mail.megapathdsl.net (CommuniGate Pro SMTP 4.1.8) with ESMTP id 172482636; Thu, 03 Jun 2004 10:20:54 -0700 Message-ID: <40BF5E34.97B4473B@rcom-software.com> Date: Thu, 03 Jun 2004 10:21:56 -0700 From: Paul Romero Organization: RCOM Communications Software X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en,es,de-DE,fr-FR MIME-Version: 1.0 To: ietf-sasl@imc.org, phoffman@imc.org Subject: Use of AUTH with SMTP 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: Dear SASL User Group Can anybody provide some insight into the following questions about how the AUTH mechanism is used with SMTP ? 1) How commonly deployed is the AUTH mechanism--as described in RFC 2554--in commercial ISP SMTP implementations ? 2) Is the CRAM-MD5 variant normally used ? If not, which others are commonly used ? 3) Is the AUTH mechanism usually implemented on a stand alone basis or in conjunction with other service--for instance TLS ? 3.1) If it is implemented with other services, what are the relevant RFCs ? Best Regards, Paul Romero -- Paul Romero RCOM Communications Software Phone/Fax: (510)339-2628 E-Mail: paulr@rcom-software.com From owner-ietf-sasl Fri Jun 4 08:56:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54FuGp8037722; Fri, 4 Jun 2004 08:56:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i54FuGAF037721; Fri, 4 Jun 2004 08:56:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54FuE5X037710 for ; Fri, 4 Jun 2004 08:56:14 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i54Fswqf045171; Fri, 4 Jun 2004 15:55:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040603232331.049a3188@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 04 Jun 2004 08:54:54 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: Use of NFKC in SASLprep Cc: ietf-sasl@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i54FuF5X037716 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 04:19 PM 4/22/2004, Simon Josefsson wrote: >FYI, as SASLprep is using NFKC per Unicode 3.2, you might be >interested in the NFKC stability problem discussed on >. The page mention a >strategy to maintain stability across NFKC revisions, which might be >relevant for SASLPrep. I'd be interested to hear people's opinions on >the problem. I recently consulted with authors of [Stringprep] (namely Paul Hoffman) as well as our liaison to the UTC (Patrik Fältström) regarding this [SASLprep] concern. They recommend that the SASLprep I-D not attempt to fix the issue discussed in PR#29. They argue (as I understand their arguments) that it would be inappropriate for SASLprep, a profile of Stringprep, to apply PR#29 to a version of Unicode instead of utilize Unicode normalization as required by Stringprep. Or, to say it in another way, PR#29 issues in a consistent manner for all profiles of Stringprep and hence ought to be handled as part of the ongoing revision of Stringprep (and its normative references). They suggest we not wait for this revision. I fully support with their recommendation (which is consistent with my prior recommendations to the WG). We also had a discussion as to wether the SASLprep I-D should note the existence of this issue (without any fix) and its impact upon implementations (and use) of SASLprep. They argued that such would be inappropriate for SASLprep I-D to include such as there no issue specific to the SASLprep profile of Stringprep here. They noted it **might** be appropriate to publish an Informational RFC updating [Stringprep]. While I have some mild reservations, I can support this recommendation. Please consider these recommendations. Sam (as chair) and I (as editor) intend to response to the IESG comment regarding concern within the next week. Kurt From owner-ietf-sasl Sat Jun 5 05:20:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i55CK2u5088727; Sat, 5 Jun 2004 05:20:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i55CK2Y7088726; Sat, 5 Jun 2004 05:20:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i55CJvWM088704 for ; Sat, 5 Jun 2004 05:19:58 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BWa9U-00048X-00 for ; Sat, 05 Jun 2004 14:19:56 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 05 Jun 2004 14:19:56 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 05 Jun 2004 14:19:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Use of NFKC in SASLprep Date: Sat, 05 Jun 2004 14:19:48 +0200 Lines: 70 Message-ID: References: <6.0.1.1.0.20040603232331.049a3188@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:/eeEHBfvkEPyendj6K8TeUuxiQQ= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > We also had a discussion as to wether the SASLprep I-D should > note the existence of this issue (without any fix) and its > impact upon implementations (and use) of SASLprep. They argued > that such would be inappropriate for SASLprep I-D to include > such as there no issue specific to the SASLprep profile of > Stringprep here. So, what do we have here? There is a known specification ambiguity in NFKC that, for example, appear to allow implementations to return three distinct output from the input string U+0B47 U+0300 U+0B3E U+0323 (see earlier discussion). This is an interoperability problem. It appears to make SASLPrep2 more complicated to specify (since SASLprep is not idempotent), with consequences for SASL user database migration (if prepared strings are stored in the database, which I have suggested shouldn't be the case in another thread). It is difficult to see that this property is impossible to abuse when attacking systems that use SASLprep on authentication/authorization tokens. And the conclusion? Let's ignore the issue, and make sure it is not even mentioned. Speaking as an implementor, I hesitate to expose my users to this issue. The conservative approach appear to be to enforce, in the implementation, a local policy of rejecting the ambiguous input strings directly. This remove the need to worry about this issue, without any obvious negative consequences (correct me if I'm wrong). Applying the same conservative approach to the specification seem possible. The drawback of doing so? We have to describe how implementions should detect and reject the ambiguous combination of code points. The advantage? Implementors aren't exposed to interoperability and security issues. Further, migrating to SASLprep2 may be simpler since it is more likely to be able to assume SASLprep is idempotent. Below is a proposal for this section, and I hope it can be considered. If the text, or something similar to it, is not adopted, I feel that at least acknowledging the issue would be appropriate. The ambiguity in NFKC doesn't disappear even if you refuse to acknowledge it. What do other implementors think? Have you compared the NFKC implementation you use with the test vectors in PR-29? Thanks, Simon 2.3.1 Prohibited Output Of Problem Sequences The algorithm used by [StringPrep] to normalize sequences have been discovered [PR-29] to be non-idempotent. Fortunately, this appear to only affect a restricted set of combination of code points, and none of those combinations are believed to occur naturally (due to different linguistic uses of the characters). Idempotency of the SASLprep operation is important for interoperability, security, and migration to revised versions of SASLprep. Thus, this section prohibit the problem sequences from occurring in SASLprep output. The logic to detect and prohibit the problem sequences uses the tables from [PR-29]. The problem sequences begin with a code point from one row in column 1 of table 1, followed by one or more of the 163 code points with a non-zero Canonical Combination Class (see Table 2), followed by one of the code points in the same row, in column 2 of Table, corresponding to the row of the first code point. [Table 1 is table 2 from .] [Table 2 is the non-zero entries of ] From owner-ietf-sasl Sat Jun 5 17:40:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i560eD5X076741; Sat, 5 Jun 2004 17:40:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i560eDto076739; Sat, 5 Jun 2004 17:40:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mariner.pc.cs.cmu.edu (dsl093-061-085.pit1.dsl.speakeasy.net [66.93.61.85]) by above.proper.com (8.12.11/8.12.9) with SMTP id i560eAwx076729 for ; Sat, 5 Jun 2004 17:40:10 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa31514; 5 Jun 2004 20:39 EDT Date: Sat, 05 Jun 2004 20:39:46 -0400 From: Jeffrey Hutzelman To: Simon Josefsson , ietf-sasl@imc.org Subject: Re: Use of NFKC in SASLprep Message-ID: <40110000.1086482386@mariner.pc.cs.cmu.edu> In-Reply-To: References: <6.0.1.1.0.20040603232331.049a3188@127.0.0.1> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Saturday, June 05, 2004 14:19:48 +0200 Simon Josefsson wrote: > So, what do we have here? There is a known specification ambiguity in > NFKC that, for example, appear to allow implementations to return > three distinct output from the input string U+0B47 U+0300 U+0B3E > U+0323 (see earlier discussion). This is an interoperability problem. > It appears to make SASLPrep2 more complicated to specify (since > SASLprep is not idempotent), with consequences for SASL user database > migration (if prepared strings are stored in the database, which I > have suggested shouldn't be the case in another thread). It is > difficult to see that this property is impossible to abuse when > attacking systems that use SASLprep on authentication/authorization > tokens. And the conclusion? Let's ignore the issue, and make sure it > is not even mentioned. It strikes me that people are blowing this way out of proportion, and I really dislike the repeated attempts in this working group to "fix" Unicode, which is _way way way_ out of scope for us. There is not a problem with NFKC. There is a TYPO in the document which specifies it. If NFKC is implemented correctly, as is done by multiple implementations _including the sample implementation in the same document_, there is no problem. This is not the end of the world. We've certainly had similar problems in IETF documents; the RFC Editor has a long list of errata for published RFC's. I cannot imagine that the Unicode Consortium will not publish a corrigendum to correct the erroneous document. In the meantime, because SASLprep will be used in security-sensitive applications including SASL and Kerberos, I think it is appropriate to include a reference to PR-29 and a recommendation that implementors insure that NFKC is implemented correctly. I do _not_ think it is appropriate to suggest behaviour _other_ than simply implementing NFKC correctly. For example, I don't think it's appropriate to specify that a large class of sequences be prohibited from output. Any implementation which would be in a position to implement such a suggestion is _also_ in a position to get NFKC right in the first place, thereby avoiding the entire problem. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From owner-ietf-sasl Sun Jun 6 03:20:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i56AKCsk032750; Sun, 6 Jun 2004 03:20:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i56AKCWH032749; Sun, 6 Jun 2004 03:20:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i56AK7up032741 for ; Sun, 6 Jun 2004 03:20:08 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BWul6-0000M3-00 for ; Sun, 06 Jun 2004 12:20:08 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 06 Jun 2004 12:20:08 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 06 Jun 2004 12:20:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Use of NFKC in SASLprep Date: Sun, 06 Jun 2004 12:20:03 +0200 Lines: 25 Message-ID: References: <6.0.1.1.0.20040603232331.049a3188@127.0.0.1> <40110000.1086482386@mariner.pc.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:RZeeepijxtJ6QM25COpKhxxPWz4= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman writes: > There is not a problem with NFKC. There is a TYPO in the document > which specifies it. If NFKC is implemented correctly, as is done by > multiple implementations _including the sample implementation in the > same document_, there is no problem. I spoke to other implementors of StringPrep, which do implement NFKC the same way as the reference implementation (i.e., not according to the letter of the specification), and one of the Stringprep authors had told them that then they were simply not following the current specifications. I think a public statement committing to one of the two interpretation (i.e., either consider it a typo in the old version of NFKC, or that the typo corrected NFKC will be a new version, which StringPrep doesn't use yet) of this problem would be useful. > In the meantime, because SASLprep will be used in security-sensitive > applications including SASL and Kerberos, I think it is appropriate to > include a reference to PR-29 and a recommendation that implementors > insure that NFKC is implemented correctly. We agree about this. Thanks, Simon From owner-ietf-sasl Mon Jun 7 14:45:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i57LjKvM005557; Mon, 7 Jun 2004 14:45:20 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i57LjKwV005556; Mon, 7 Jun 2004 14:45:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i57LjJ7O005549 for ; Mon, 7 Jun 2004 14:45:19 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 32057151F18; Mon, 7 Jun 2004 17:45:23 -0400 (EDT) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: Use of NFKC in SASLprep References: <6.0.1.1.0.20040603232331.049a3188@127.0.0.1> From: Sam Hartman Date: Mon, 07 Jun 2004 17:45:23 -0400 In-Reply-To: (Simon Josefsson's message of "Sat, 05 Jun 2004 14:19:48 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) 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: >>>>> "Simon" == Simon Josefsson writes: Simon> appears to make SASLPrep2 more complicated to specify Simon> (since SASLprep is not idempotent), with consequences for Simon> SASL user database migration (if prepared strings are Simon> stored in the database, which I have suggested shouldn't be Simon> the case in another thread). As someone who tends to believe that prepared strings should be stored in the database, I think it is worth working through the issues of what we will do with saslprep2 now. My presumption is that we go forward assuming that saslprep is idempotent even though we know it is not. That is, we ignore this issue now and for all future versions of saslprep. --Sam From owner-ietf-sasl Fri Jun 18 13:18:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IKITKF067550; Fri, 18 Jun 2004 13:18:29 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5IKITeB067549; Fri, 18 Jun 2004 13:18:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fe.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IKISZd067536 for ; Fri, 18 Jun 2004 13:18:28 -0700 (PDT) (envelope-from paulr@rcom-software.com) Received: from [64.139.27.223] (HELO rcom-software.com) by fe.mail.megapathdsl.net (CommuniGate Pro SMTP 4.1.8) with ESMTP id 157475961; Fri, 18 Jun 2004 13:18:27 -0700 Message-ID: <40D34E54.9C380C49@rcom-software.com> Date: Fri, 18 Jun 2004 13:19:32 -0700 From: Paul Romero Organization: RCOM Communications Software X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en,es,de-DE,fr-FR MIME-Version: 1.0 To: libesmtpd-devel@community.uklinux.net CC: ietf-sasl@imc.org Subject: LIBESMTPD: E-Mail Client on UC Linux ? 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: Dear Brian and LIBESMTP Aficionados: I downloaded the Debian version of the libesmtp source code and can now send E-mail with the sample program--provided with libesmtp-dev, under the following conditions. (i.e. My system does not provide an SMTP server.) The Linux "inetd" has established an Internet connection, TCP port number 25 is used, and the host--as specified with "-h"-- identifies a system that provides SMTP service. (i.e. I used symbolic names for the mail servers.) Some seemingly important modifications were required which are detailed below--as well as the other significant factors. My system runs Linux "inetd" over an Ethernet card, but I suspect this would work with a modem connection once the IP/PPP to ISP connection is established with cooperation from Linux "pppd" and "inetd". Also, I did not actually try the AUTH capability. I plan to use my SMTP software to connect directly to SMTP servers--without additional forwarding or queuing software--and would like more insight into the following general issues: (i.e. My application is an MTA only between the PC and the ISP SMTP Server--virtually an MUA.) * Is the libesmtp package described on the website significantly different than the Linux version--libesmtp5 and libesmtp-dev ? * Does libesmtp provide DIGEST-MD5 and GSS API-Kerberos authentication as well as CRAM-MD5 ? If not, what are the future plans in this respect ? * Is libesmpt robust enough to handle direct connections to SMTP servers--via TCP/IP ? (i.e. Not on my local system.) * Has libesmtp been ported to UC Linux or would you recommend doing so ? (i.e. Memory space is quite limited.) * Do you know of US ISPs that would allow low cost experimentation with the AUTH mechanism ? * What part of the documentation describes how to configure the "secret" etc. as used by the CRAM-MD5 variant of AUTH ? * Would it be difficult to modify the libesmtp to facilitate the transmission of streaming E-mail ? (i.e. Multiple user data writes after a positive 354 response to the SMTP DATA command instead of retrieving data from a file.) If you feel that libesmtpd is not appropriate for the environment I described, can you recommend another software package ? Finally, the details I mentioned earlier follow. Best Regards, Paul Romero MODIFICATIONS The libesmtp-dev software had to be recompiled and reinstalled with the following modifications before E-mail could be sent. had to be set up for a UDP Datagram socket. * The sample program was modified pass both the host name and TCP port number 25 to the lower level software. * Before calling getaddrinfo() the parameters had to be set up for a UDP Datagram socket. (i.e. In protocol.c) The relevant parameters-- mostly in the "hints" structure are as follows: . Protocol Family: PF_INET . Socket Type: SOCK_DGRAM . Protocol: IPPROTO_UDP . Flags: AI_CANONNAME (i.e. ai_canonname set to the host name which is also passed as an argument to getaddrinfo().) Notes: The exact details are particular to Debian but, I suspect they don't vary much on most versions of Linux. Also, there is only 1 getaddrinfo() call in the whole file. * The socket() call to establish a connection had to be modified to setup up a TCP streaming socket. (i.e. In protocol.c) The socket() arguments are as follows: . domain: PF_INET . type: SOCK_STREAM . protocols: 0 (i.e. Mandatory for Debian.) Note: There is only 1 getaddrinfo() call in the same file, and I think this will work for all versions of Linux. SMTP SOFTWARE * Standard Debian Version of libesmtp5--version 0.8--and libesmtp-dev--Version 8.11--packages. (i.e. Downloaded these from the Debian website.) PROTOCOL SETUP * Standard Linux & Socket TCP/IP tools. * IP over LLC2 (i.e. via conventional Linux "inetd") * Ethernet Card attached to PC Bus and connected to Netopia DSL router. * DSL router uses ADSL and exchanges date via ATM with the DSLAM at the CO. HARDWARE ENVIRONMENT * Normal Intel Based PC * Ethernet Card * Netopia DSL Router OS * Stock distribute of "Woody" Debian Linux. (i.e. Release 2.2.17 ) -- Paul Romero RCOM Communications Software Phone/Fax: (510)339-2628 E-Mail: paulr@rcom-software.com From owner-ietf-sasl Fri Jun 18 14:05:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IL5hos072283; Fri, 18 Jun 2004 14:05:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5IL5hct072282; Fri, 18 Jun 2004 14:05:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fe.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IL5gJO072258 for ; Fri, 18 Jun 2004 14:05:42 -0700 (PDT) (envelope-from paulr@rcom-software.com) Received: from [64.139.27.223] (HELO rcom-software.com) by fe.mail.megapathdsl.net (CommuniGate Pro SMTP 4.1.8) with ESMTP id 177133214; Fri, 18 Jun 2004 14:05:41 -0700 Message-ID: <40D35966.C74DA943@rcom-software.com> Date: Fri, 18 Jun 2004 14:06:46 -0700 From: Paul Romero Organization: RCOM Communications Software X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en,es,de-DE,fr-FR MIME-Version: 1.0 To: ietf-sasl@imc.org, uclinux-dev@uclinux.org CC: hroskos@cermetek.com, email@joernweber.de, mel@isode.com Subject: SMTP/AUTH Software Recommendation 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: Hi Folks: Could you recommend a stand alone SMTP CLIENT software package that satisfies the following criteria ? * It provides the following AUTH mechanisms in order of importance: CRAM-MD5, DIGEST-MD5, and GSS API-Kerberos. (i.e. Don't really need TLS.) * Has an API accessible via C subroutine calls. * Is independent of TCP/IP connection media-- modem, ethernet etc. * Uses a relatively small amount of memory. * Runs on Linux in user space using only standard Linux tools and socket calls, and relies only on Linux "inetd" and "pppd". * Sends E-mail directly to SMTP servers without local queuing or additional MTAs. * Is ported or can easily be ported to UC Linux. * Can accept multiple user data API writes after a successful 354 response to the SMTP DATA command. (i.e. Streaming E-mail.) Any comments or insight would be appreciated. Best Regards, Paul R. -- Paul Romero RCOM Communications Software Phone/Fax: (510)339-2628 E-Mail: paulr@rcom-software.com From owner-ietf-sasl Mon Jun 21 16:27:37 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LNRbgv094519; Mon, 21 Jun 2004 16:27:37 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LNRbBK094518; Mon, 21 Jun 2004 16:27:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LNRXY4094437 for ; Mon, 21 Jun 2004 16:27:35 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust180.tnt24.lnd4.gbr.da.uu.net [62.188.151.180]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 22 Jun 2004 00:28:03 +0100 Message-ID: <40D7666B.7070001@isode.com> Date: Mon, 21 Jun 2004 23:51:23 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: SASL WG Subject: Final changes to the base SASL document References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: >On Fri, 21 May 2004, Sam Hartman wrote: > > >> >> It seems we can handle this cleanly enough if we treat it just >> >> like the initial response. >> >>But is it worth the complexity? IT seems that if we can avoid the >>introduction of distinguishing the two cases we should do so. >> >> > >If it is not worth the complexity (and, really, I can't think of any >situation where an empty server success data would be *useful*-- it just >seems that we'd be giving up some level of flexibility), then we should >just forbid empty success data -- this would lead to the less confusion >than attributing two potential meanings to "no success data". > > Should I treat "forbid empty success data" as the WG consensus on empty versa no data on success? I would like to publish [the last] revision of the base SASL spec. Alexey From owner-ietf-sasl Mon Jun 21 16:28:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LNSgna094758; Mon, 21 Jun 2004 16:28:42 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LNSg8L094757; Mon, 21 Jun 2004 16:28:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LNSe5E094743 for ; Mon, 21 Jun 2004 16:28:41 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust180.tnt24.lnd4.gbr.da.uu.net [62.188.151.180]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 22 Jun 2004 00:28:48 +0100 Message-ID: <40D76891.4030703@isode.com> Date: Tue, 22 Jun 2004 00:00:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Ken Murchison CC: "Kurt D. Zeilenga" , Rob Siemborski , SASL WG Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> <6.0.1.1.0.20040521094503.0483fe28@127.0.0.1> <6.0.1.1.0.20040521103442.049371d8@127.0.0.1> <6.0.1.1.0.20040521105853.0483ca98@127.0.0.1> <6.0.1.1.0.20040521111921.0493f458@127.0.0.1> <6.0.1.1.0.20040521114345.02cb9138@127.0.0.1> <40AE6276.4010706@oceana.com> <40AE68CC.9030900@oceana.com> In-Reply-To: <40AE68CC.9030900@oceana.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison wrote: > Ken Murchison wrote: > >> Kurt D. Zeilenga wrote: >> >>> At 11:41 AM 5/21/2004, Rob Siemborski wrote: >>> >>>> It also states: >>>> >>>> 7.4. External mechanism >>>> The client sends an initial response with the authorization identity. >>> >>> Note that it does not say: >>> The client may optionally send an initial response with the >>> authorization >>> identity. >>> >>> And, if the client were not to send an initial response, there is no >>> specified challenge for the server to issue to obtain the authorization >>> identity. >> >> I think the problem here is that the EXTERNAL spec uses the term >> "initial response" which is implying that the response can only be >> sent with the command which starts the authentication. My >> understanding is that EXTERNAL consists of a single message sent from >> client to server which contains the authzid. If the protocol profile >> allows for an initial response and the client chooses to do so, then >> the authzid MAY be sent as an initial response. Otherwise, the >> server will send an empty challenge to prompt the client for the >> authzid. Either way, the client MUST provide an authzid. > > > I should have added the following to my last sentence: "which may be > empty". I've changed the paragraph to be: The client sends a single message containing the UTF-8 encoding of the authorization identity. The message may be empty. The form of the authorization identity is further restricted by the application-level protocol's SASL profile. Alexey From owner-ietf-sasl Thu Jun 24 10:35:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OHZQ3i078059; Thu, 24 Jun 2004 10:35:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OHZQbK078058; Thu, 24 Jun 2004 10:35:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fe.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OHZQc6078051 for ; Thu, 24 Jun 2004 10:35:26 -0700 (PDT) (envelope-from paulr@rcom-software.com) Received: from [64.139.27.223] (HELO rcom-software.com) by fe.mail.megapathdsl.net (CommuniGate Pro SMTP 4.1.8) with ESMTP id 178852070 for ietf-sasl@imc.org; Thu, 24 Jun 2004 10:35:24 -0700 Message-ID: <40DB111C.315EB785@rcom-software.com> Date: Thu, 24 Jun 2004 10:36:28 -0700 From: Paul Romero Organization: RCOM Communications Software X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en,es,de-DE,fr-FR MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Validation of SASL/AUTH Features 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: Dear SASL Group: I need to perform some experiments with AUTH functionality. Can anybody recommend ISPs which operate in Northern California and offer a variety of AUTH features. My particular interest is CRAM-MD5 without a dial up connection. Best Regards, Paul R. -- Paul Romero RCOM Communications Software Phone/Fax: (510)339-2628 E-Mail: paulr@rcom-software.com From owner-ietf-sasl Thu Jun 24 21:02:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P42ct6033953; Thu, 24 Jun 2004 21:02:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P42cWC033952; Thu, 24 Jun 2004 21:02:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P42ccV033944 for ; Thu, 24 Jun 2004 21:02:38 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i5P42gMC017880 for ; Fri, 25 Jun 2004 04:02:42 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040624205012.04833890@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 24 Jun 2004 21:02:47 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Re: Use of NFKC in SASLprep In-Reply-To: References: <6.0.1.1.0.20040603232331.049a3188@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 02:45 PM 6/7/2004, Sam Hartman wrote: >My presumption is that we go forward assuming that saslprep is >idempotent even though we know it is not. That is, we ignore this >issue now and for all future versions of saslprep. I have written the following text, replacing the first paragraph of the Security Consideration discussion, to make note of the issue. This profile is intended to used to prepare simple user names and passwords strings for comparison or use in cryptographic functions (e.g., message digests). The preparation algorithm was specifically designed such that its output is canonical, and it is for well-formed. However, due to an anomaly [PR29] in specification of Unicode normalization, canonical equivalence is not guaranteed for a select few character sequences. These sequences, however, do not appear in well-formed text. This specification was published despite this known technical problem. It is expected that this specification will be revised before further progression on the Standards Track (after [Unicode] and/or [StringPrep] specifications have been updated to address this problem). Comments? Alternative wording? Kurt From owner-ietf-sasl Fri Jun 25 03:38:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PAc4wZ059335; Fri, 25 Jun 2004 03:38:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PAc4P3059334; Fri, 25 Jun 2004 03:38:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PAc0EQ059326 for ; Fri, 25 Jun 2004 03:38:01 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Bdo5i-00023Z-00 for ; Fri, 25 Jun 2004 12:37:54 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Jun 2004 12:37:54 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Jun 2004 12:37:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Use of NFKC in SASLprep Date: Fri, 25 Jun 2004 12:37:49 +0200 Lines: 34 Message-ID: References: <6.0.1.1.0.20040603232331.049a3188@127.0.0.1> <6.0.1.1.0.20040624205012.04833890@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:0DFje/vO2qsGqLW6ur2X7TenZvI= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > At 02:45 PM 6/7/2004, Sam Hartman wrote: >>My presumption is that we go forward assuming that saslprep is >>idempotent even though we know it is not. That is, we ignore this >>issue now and for all future versions of saslprep. > > I have written the following text, replacing the first paragraph > of the Security Consideration discussion, to make note of the > issue. > > This profile is intended to used to prepare simple user names and > passwords strings for comparison or use in cryptographic functions > (e.g., message digests). The preparation algorithm was specifically > designed such that its output is canonical, and it is for well-formed. ^^^^^^^^^^^^^^^^^^^^^^^^^^ I have trouble parsing the last part? > However, due to an anomaly [PR29] in specification of Unicode > normalization, canonical equivalence is not guaranteed for a select > few character sequences. These sequences, however, do not appear > in well-formed text. This specification was published despite > this known technical problem. It is expected that this specification > will be revised before further progression on the Standards Track > (after [Unicode] and/or [StringPrep] specifications have been updated > to address this problem). > > Comments? Alternative wording? Otherwise it looks fine to me! Thanks, Simon From owner-ietf-sasl Fri Jun 25 08:31:21 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PFVKWr085412; Fri, 25 Jun 2004 08:31:21 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PFVKhr085411; Fri, 25 Jun 2004 08:31:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PFVJm0085403 for ; Fri, 25 Jun 2004 08:31:19 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i5PFUBMC023379; Fri, 25 Jun 2004 15:30:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040625082919.04bb84c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 25 Jun 2004 08:30:15 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: Use of NFKC in SASLprep Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040603232331.049a3188@127.0.0.1> <6.0.1.1.0.20040624205012.04833890@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 03:37 AM 6/25/2004, Simon Josefsson wrote: >>and it is for well-formed. > ^^^^^^^^^^^^^^^^^^^^^^^^^^ >I have trouble parsing the last part? s/well-formed/well-formed text/ Kurt From owner-ietf-sasl Fri Jun 25 10:34:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PHYGPr094668; Fri, 25 Jun 2004 10:34:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PHYGWP094667; Fri, 25 Jun 2004 10:34:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PHYGGp094661 for ; Fri, 25 Jun 2004 10:34:16 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i5PHYJMC024386 for ; Fri, 25 Jun 2004 17:34:19 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040625103414.04bd6ad8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 25 Jun 2004 10:34:23 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: bounces when posting to this list 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: I recently noticed that mail to one of the list subscribers was being bounced back to poster (instead of to the list owner... or not at all) asking the post to click on some URL. I've sent a note to this subscriber to fix their problem and intend to remove the subscriber if their problem is not soon corrected. If you noticed such problems, you should feel free to complain to chairs and/or . Kurt SASL co-chair From owner-ietf-sasl Mon Jun 28 12:35:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SJZKfC005795; Mon, 28 Jun 2004 12:35:20 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5SJZKo9005794; Mon, 28 Jun 2004 12:35:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SJZJaw005781 for ; Mon, 28 Jun 2004 12:35:19 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25861; Mon, 28 Jun 2004 15:35:21 -0400 (EDT) Message-Id: <200406281935.PAA25861@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-gssapi-01.txt Date: Mon, 28 Jun 2004 15:35:21 -0400 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 : SASL GSSAPI mechanisms Author(s) : A. Melnikov Filename : draft-ietf-sasl-gssapi-01.txt Pages : 15 Date : 2004-6-28 The Simple Authentication and Security Layer [SASL] is a method for adding authentication support to connection-based protocols. This document describes the method for using the Generic Security Service Application Program Interface [GSSAPI] in the Simple Authentication and Security Layer [SASL]. This document replaces section 7.2 of RFC 2222 [SASL], the definition of the 'GSSAPI' SASL mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-gssapi-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-gssapi-01.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-gssapi-01.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: <2004-6-28151329.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-gssapi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-gssapi-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-28151329.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Tue Jun 29 12:29:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TJTDUO017875; Tue, 29 Jun 2004 12:29:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TJTD1P017874; Tue, 29 Jun 2004 12:29:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TJTCa9017867 for ; Tue, 29 Jun 2004 12:29:12 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11485; Tue, 29 Jun 2004 15:29:15 -0400 (EDT) Message-Id: <200406291929.PAA11485@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-08.txt Date: Tue, 29 Jun 2004 15:29:15 -0400 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 : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-08.txt Pages : 11 Date : 2004-6-29 The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-based protocols. It also describes a structure for authentication mechanisms. The result is an abstraction layer between protocols and authentication mechanisms such that any SASL- compatible authentication mechanism can be used with any SASL- compatible protocol. This document describes how a SASL authentication mechanism is structured, describes how a protocol adds support for SASL, defines the protocol for carrying a security layer over a connection, and defines the SASL EXTERNAL authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rfc2222bis-08.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-rfc2222bis-08.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: <2004-6-29150243.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-29150243.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Wed Jun 30 02:51:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U9psP4074146; Wed, 30 Jun 2004 02:51:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5U9psuA074145; Wed, 30 Jun 2004 02:51:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U9pq6s074135 for ; Wed, 30 Jun 2004 02:51:53 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 30 Jun 2004 10:53:02 +0100 Message-ID: <40E1381F.4020409@isode.com> Date: Tue, 29 Jun 2004 10:36:31 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: SASL WG Subject: New revision of draft-ietf-sasl-gssapi References: <40DC9563.4070006@isode.com> In-Reply-To: <40DC9563.4070006@isode.com> 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: Version 00 has expired recently. I've submitted -01 which was announced today. Only minor tweaks in this version: updated Copyright, clarified that authorization id is in UTF-8. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U9psP4074146; Wed, 30 Jun 2004 02:51:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5U9psuA074145; Wed, 30 Jun 2004 02:51:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U9pq6s074135 for ; Wed, 30 Jun 2004 02:51:53 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 30 Jun 2004 10:53:02 +0100 Message-ID: <40E1381F.4020409@isode.com> Date: Tue, 29 Jun 2004 10:36:31 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: SASL WG Subject: New revision of draft-ietf-sasl-gssapi References: <40DC9563.4070006@isode.com> In-Reply-To: <40DC9563.4070006@isode.com> 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: Version 00 has expired recently. I've submitted -01 which was announced today. Only minor tweaks in this version: updated Copyright, clarified that authorization id is in UTF-8. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TJTDUO017875; Tue, 29 Jun 2004 12:29:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TJTD1P017874; Tue, 29 Jun 2004 12:29:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TJTCa9017867 for ; Tue, 29 Jun 2004 12:29:12 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11485; Tue, 29 Jun 2004 15:29:15 -0400 (EDT) Message-Id: <200406291929.PAA11485@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-08.txt Date: Tue, 29 Jun 2004 15:29:15 -0400 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 : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-08.txt Pages : 11 Date : 2004-6-29 The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-based protocols. It also describes a structure for authentication mechanisms. The result is an abstraction layer between protocols and authentication mechanisms such that any SASL- compatible authentication mechanism can be used with any SASL- compatible protocol. This document describes how a SASL authentication mechanism is structured, describes how a protocol adds support for SASL, defines the protocol for carrying a security layer over a connection, and defines the SASL EXTERNAL authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rfc2222bis-08.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-rfc2222bis-08.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: <2004-6-29150243.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-29150243.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SJZKfC005795; Mon, 28 Jun 2004 12:35:20 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5SJZKo9005794; Mon, 28 Jun 2004 12:35:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SJZJaw005781 for ; Mon, 28 Jun 2004 12:35:19 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25861; Mon, 28 Jun 2004 15:35:21 -0400 (EDT) Message-Id: <200406281935.PAA25861@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-gssapi-01.txt Date: Mon, 28 Jun 2004 15:35:21 -0400 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 : SASL GSSAPI mechanisms Author(s) : A. Melnikov Filename : draft-ietf-sasl-gssapi-01.txt Pages : 15 Date : 2004-6-28 The Simple Authentication and Security Layer [SASL] is a method for adding authentication support to connection-based protocols. This document describes the method for using the Generic Security Service Application Program Interface [GSSAPI] in the Simple Authentication and Security Layer [SASL]. This document replaces section 7.2 of RFC 2222 [SASL], the definition of the 'GSSAPI' SASL mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-gssapi-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-gssapi-01.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-gssapi-01.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: <2004-6-28151329.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-gssapi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-gssapi-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-28151329.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PHYGPr094668; Fri, 25 Jun 2004 10:34:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PHYGWP094667; Fri, 25 Jun 2004 10:34:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PHYGGp094661 for ; Fri, 25 Jun 2004 10:34:16 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i5PHYJMC024386 for ; Fri, 25 Jun 2004 17:34:19 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040625103414.04bd6ad8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 25 Jun 2004 10:34:23 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: bounces when posting to this list 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: I recently noticed that mail to one of the list subscribers was being bounced back to poster (instead of to the list owner... or not at all) asking the post to click on some URL. I've sent a note to this subscriber to fix their problem and intend to remove the subscriber if their problem is not soon corrected. If you noticed such problems, you should feel free to complain to chairs and/or . Kurt SASL co-chair Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PFVKWr085412; Fri, 25 Jun 2004 08:31:21 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PFVKhr085411; Fri, 25 Jun 2004 08:31:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PFVJm0085403 for ; Fri, 25 Jun 2004 08:31:19 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i5PFUBMC023379; Fri, 25 Jun 2004 15:30:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040625082919.04bb84c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 25 Jun 2004 08:30:15 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: Use of NFKC in SASLprep Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040603232331.049a3188@127.0.0.1> <6.0.1.1.0.20040624205012.04833890@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 03:37 AM 6/25/2004, Simon Josefsson wrote: >>and it is for well-formed. > ^^^^^^^^^^^^^^^^^^^^^^^^^^ >I have trouble parsing the last part? s/well-formed/well-formed text/ Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PAc4wZ059335; Fri, 25 Jun 2004 03:38:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PAc4P3059334; Fri, 25 Jun 2004 03:38:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PAc0EQ059326 for ; Fri, 25 Jun 2004 03:38:01 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Bdo5i-00023Z-00 for ; Fri, 25 Jun 2004 12:37:54 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Jun 2004 12:37:54 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Jun 2004 12:37:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Use of NFKC in SASLprep Date: Fri, 25 Jun 2004 12:37:49 +0200 Lines: 34 Message-ID: References: <6.0.1.1.0.20040603232331.049a3188@127.0.0.1> <6.0.1.1.0.20040624205012.04833890@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:0DFje/vO2qsGqLW6ur2X7TenZvI= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > At 02:45 PM 6/7/2004, Sam Hartman wrote: >>My presumption is that we go forward assuming that saslprep is >>idempotent even though we know it is not. That is, we ignore this >>issue now and for all future versions of saslprep. > > I have written the following text, replacing the first paragraph > of the Security Consideration discussion, to make note of the > issue. > > This profile is intended to used to prepare simple user names and > passwords strings for comparison or use in cryptographic functions > (e.g., message digests). The preparation algorithm was specifically > designed such that its output is canonical, and it is for well-formed. ^^^^^^^^^^^^^^^^^^^^^^^^^^ I have trouble parsing the last part? > However, due to an anomaly [PR29] in specification of Unicode > normalization, canonical equivalence is not guaranteed for a select > few character sequences. These sequences, however, do not appear > in well-formed text. This specification was published despite > this known technical problem. It is expected that this specification > will be revised before further progression on the Standards Track > (after [Unicode] and/or [StringPrep] specifications have been updated > to address this problem). > > Comments? Alternative wording? Otherwise it looks fine to me! Thanks, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P42ct6033953; Thu, 24 Jun 2004 21:02:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P42cWC033952; Thu, 24 Jun 2004 21:02:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P42ccV033944 for ; Thu, 24 Jun 2004 21:02:38 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i5P42gMC017880 for ; Fri, 25 Jun 2004 04:02:42 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040624205012.04833890@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 24 Jun 2004 21:02:47 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Re: Use of NFKC in SASLprep In-Reply-To: References: <6.0.1.1.0.20040603232331.049a3188@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 02:45 PM 6/7/2004, Sam Hartman wrote: >My presumption is that we go forward assuming that saslprep is >idempotent even though we know it is not. That is, we ignore this >issue now and for all future versions of saslprep. I have written the following text, replacing the first paragraph of the Security Consideration discussion, to make note of the issue. This profile is intended to used to prepare simple user names and passwords strings for comparison or use in cryptographic functions (e.g., message digests). The preparation algorithm was specifically designed such that its output is canonical, and it is for well-formed. However, due to an anomaly [PR29] in specification of Unicode normalization, canonical equivalence is not guaranteed for a select few character sequences. These sequences, however, do not appear in well-formed text. This specification was published despite this known technical problem. It is expected that this specification will be revised before further progression on the Standards Track (after [Unicode] and/or [StringPrep] specifications have been updated to address this problem). Comments? Alternative wording? Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OHZQ3i078059; Thu, 24 Jun 2004 10:35:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OHZQbK078058; Thu, 24 Jun 2004 10:35:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fe.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OHZQc6078051 for ; Thu, 24 Jun 2004 10:35:26 -0700 (PDT) (envelope-from paulr@rcom-software.com) Received: from [64.139.27.223] (HELO rcom-software.com) by fe.mail.megapathdsl.net (CommuniGate Pro SMTP 4.1.8) with ESMTP id 178852070 for ietf-sasl@imc.org; Thu, 24 Jun 2004 10:35:24 -0700 Message-ID: <40DB111C.315EB785@rcom-software.com> Date: Thu, 24 Jun 2004 10:36:28 -0700 From: Paul Romero Organization: RCOM Communications Software X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en,es,de-DE,fr-FR MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Validation of SASL/AUTH Features 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: Dear SASL Group: I need to perform some experiments with AUTH functionality. Can anybody recommend ISPs which operate in Northern California and offer a variety of AUTH features. My particular interest is CRAM-MD5 without a dial up connection. Best Regards, Paul R. -- Paul Romero RCOM Communications Software Phone/Fax: (510)339-2628 E-Mail: paulr@rcom-software.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LNSgna094758; Mon, 21 Jun 2004 16:28:42 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LNSg8L094757; Mon, 21 Jun 2004 16:28:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LNSe5E094743 for ; Mon, 21 Jun 2004 16:28:41 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust180.tnt24.lnd4.gbr.da.uu.net [62.188.151.180]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 22 Jun 2004 00:28:48 +0100 Message-ID: <40D76891.4030703@isode.com> Date: Tue, 22 Jun 2004 00:00:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Ken Murchison CC: "Kurt D. Zeilenga" , Rob Siemborski , SASL WG Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> <6.0.1.1.0.20040521094503.0483fe28@127.0.0.1> <6.0.1.1.0.20040521103442.049371d8@127.0.0.1> <6.0.1.1.0.20040521105853.0483ca98@127.0.0.1> <6.0.1.1.0.20040521111921.0493f458@127.0.0.1> <6.0.1.1.0.20040521114345.02cb9138@127.0.0.1> <40AE6276.4010706@oceana.com> <40AE68CC.9030900@oceana.com> In-Reply-To: <40AE68CC.9030900@oceana.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison wrote: > Ken Murchison wrote: > >> Kurt D. Zeilenga wrote: >> >>> At 11:41 AM 5/21/2004, Rob Siemborski wrote: >>> >>>> It also states: >>>> >>>> 7.4. External mechanism >>>> The client sends an initial response with the authorization identity. >>> >>> Note that it does not say: >>> The client may optionally send an initial response with the >>> authorization >>> identity. >>> >>> And, if the client were not to send an initial response, there is no >>> specified challenge for the server to issue to obtain the authorization >>> identity. >> >> I think the problem here is that the EXTERNAL spec uses the term >> "initial response" which is implying that the response can only be >> sent with the command which starts the authentication. My >> understanding is that EXTERNAL consists of a single message sent from >> client to server which contains the authzid. If the protocol profile >> allows for an initial response and the client chooses to do so, then >> the authzid MAY be sent as an initial response. Otherwise, the >> server will send an empty challenge to prompt the client for the >> authzid. Either way, the client MUST provide an authzid. > > > I should have added the following to my last sentence: "which may be > empty". I've changed the paragraph to be: The client sends a single message containing the UTF-8 encoding of the authorization identity. The message may be empty. The form of the authorization identity is further restricted by the application-level protocol's SASL profile. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LNRbgv094519; Mon, 21 Jun 2004 16:27:37 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LNRbBK094518; Mon, 21 Jun 2004 16:27:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LNRXY4094437 for ; Mon, 21 Jun 2004 16:27:35 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust180.tnt24.lnd4.gbr.da.uu.net [62.188.151.180]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 22 Jun 2004 00:28:03 +0100 Message-ID: <40D7666B.7070001@isode.com> Date: Mon, 21 Jun 2004 23:51:23 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: SASL WG Subject: Final changes to the base SASL document References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: >On Fri, 21 May 2004, Sam Hartman wrote: > > >> >> It seems we can handle this cleanly enough if we treat it just >> >> like the initial response. >> >>But is it worth the complexity? IT seems that if we can avoid the >>introduction of distinguishing the two cases we should do so. >> >> > >If it is not worth the complexity (and, really, I can't think of any >situation where an empty server success data would be *useful*-- it just >seems that we'd be giving up some level of flexibility), then we should >just forbid empty success data -- this would lead to the less confusion >than attributing two potential meanings to "no success data". > > Should I treat "forbid empty success data" as the WG consensus on empty versa no data on success? I would like to publish [the last] revision of the base SASL spec. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IL5hos072283; Fri, 18 Jun 2004 14:05:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5IL5hct072282; Fri, 18 Jun 2004 14:05:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fe.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IL5gJO072258 for ; Fri, 18 Jun 2004 14:05:42 -0700 (PDT) (envelope-from paulr@rcom-software.com) Received: from [64.139.27.223] (HELO rcom-software.com) by fe.mail.megapathdsl.net (CommuniGate Pro SMTP 4.1.8) with ESMTP id 177133214; Fri, 18 Jun 2004 14:05:41 -0700 Message-ID: <40D35966.C74DA943@rcom-software.com> Date: Fri, 18 Jun 2004 14:06:46 -0700 From: Paul Romero Organization: RCOM Communications Software X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en,es,de-DE,fr-FR MIME-Version: 1.0 To: ietf-sasl@imc.org, uclinux-dev@uclinux.org CC: hroskos@cermetek.com, email@joernweber.de, mel@isode.com Subject: SMTP/AUTH Software Recommendation 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: Hi Folks: Could you recommend a stand alone SMTP CLIENT software package that satisfies the following criteria ? * It provides the following AUTH mechanisms in order of importance: CRAM-MD5, DIGEST-MD5, and GSS API-Kerberos. (i.e. Don't really need TLS.) * Has an API accessible via C subroutine calls. * Is independent of TCP/IP connection media-- modem, ethernet etc. * Uses a relatively small amount of memory. * Runs on Linux in user space using only standard Linux tools and socket calls, and relies only on Linux "inetd" and "pppd". * Sends E-mail directly to SMTP servers without local queuing or additional MTAs. * Is ported or can easily be ported to UC Linux. * Can accept multiple user data API writes after a successful 354 response to the SMTP DATA command. (i.e. Streaming E-mail.) Any comments or insight would be appreciated. Best Regards, Paul R. -- Paul Romero RCOM Communications Software Phone/Fax: (510)339-2628 E-Mail: paulr@rcom-software.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IKITKF067550; Fri, 18 Jun 2004 13:18:29 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5IKITeB067549; Fri, 18 Jun 2004 13:18:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fe.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IKISZd067536 for ; Fri, 18 Jun 2004 13:18:28 -0700 (PDT) (envelope-from paulr@rcom-software.com) Received: from [64.139.27.223] (HELO rcom-software.com) by fe.mail.megapathdsl.net (CommuniGate Pro SMTP 4.1.8) with ESMTP id 157475961; Fri, 18 Jun 2004 13:18:27 -0700 Message-ID: <40D34E54.9C380C49@rcom-software.com> Date: Fri, 18 Jun 2004 13:19:32 -0700 From: Paul Romero Organization: RCOM Communications Software X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en,es,de-DE,fr-FR MIME-Version: 1.0 To: libesmtpd-devel@community.uklinux.net CC: ietf-sasl@imc.org Subject: LIBESMTPD: E-Mail Client on UC Linux ? 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: Dear Brian and LIBESMTP Aficionados: I downloaded the Debian version of the libesmtp source code and can now send E-mail with the sample program--provided with libesmtp-dev, under the following conditions. (i.e. My system does not provide an SMTP server.) The Linux "inetd" has established an Internet connection, TCP port number 25 is used, and the host--as specified with "-h"-- identifies a system that provides SMTP service. (i.e. I used symbolic names for the mail servers.) Some seemingly important modifications were required which are detailed below--as well as the other significant factors. My system runs Linux "inetd" over an Ethernet card, but I suspect this would work with a modem connection once the IP/PPP to ISP connection is established with cooperation from Linux "pppd" and "inetd". Also, I did not actually try the AUTH capability. I plan to use my SMTP software to connect directly to SMTP servers--without additional forwarding or queuing software--and would like more insight into the following general issues: (i.e. My application is an MTA only between the PC and the ISP SMTP Server--virtually an MUA.) * Is the libesmtp package described on the website significantly different than the Linux version--libesmtp5 and libesmtp-dev ? * Does libesmtp provide DIGEST-MD5 and GSS API-Kerberos authentication as well as CRAM-MD5 ? If not, what are the future plans in this respect ? * Is libesmpt robust enough to handle direct connections to SMTP servers--via TCP/IP ? (i.e. Not on my local system.) * Has libesmtp been ported to UC Linux or would you recommend doing so ? (i.e. Memory space is quite limited.) * Do you know of US ISPs that would allow low cost experimentation with the AUTH mechanism ? * What part of the documentation describes how to configure the "secret" etc. as used by the CRAM-MD5 variant of AUTH ? * Would it be difficult to modify the libesmtp to facilitate the transmission of streaming E-mail ? (i.e. Multiple user data writes after a positive 354 response to the SMTP DATA command instead of retrieving data from a file.) If you feel that libesmtpd is not appropriate for the environment I described, can you recommend another software package ? Finally, the details I mentioned earlier follow. Best Regards, Paul Romero MODIFICATIONS The libesmtp-dev software had to be recompiled and reinstalled with the following modifications before E-mail could be sent. had to be set up for a UDP Datagram socket. * The sample program was modified pass both the host name and TCP port number 25 to the lower level software. * Before calling getaddrinfo() the parameters had to be set up for a UDP Datagram socket. (i.e. In protocol.c) The relevant parameters-- mostly in the "hints" structure are as follows: . Protocol Family: PF_INET . Socket Type: SOCK_DGRAM . Protocol: IPPROTO_UDP . Flags: AI_CANONNAME (i.e. ai_canonname set to the host name which is also passed as an argument to getaddrinfo().) Notes: The exact details are particular to Debian but, I suspect they don't vary much on most versions of Linux. Also, there is only 1 getaddrinfo() call in the whole file. * The socket() call to establish a connection had to be modified to setup up a TCP streaming socket. (i.e. In protocol.c) The socket() arguments are as follows: . domain: PF_INET . type: SOCK_STREAM . protocols: 0 (i.e. Mandatory for Debian.) Note: There is only 1 getaddrinfo() call in the same file, and I think this will work for all versions of Linux. SMTP SOFTWARE * Standard Debian Version of libesmtp5--version 0.8--and libesmtp-dev--Version 8.11--packages. (i.e. Downloaded these from the Debian website.) PROTOCOL SETUP * Standard Linux & Socket TCP/IP tools. * IP over LLC2 (i.e. via conventional Linux "inetd") * Ethernet Card attached to PC Bus and connected to Netopia DSL router. * DSL router uses ADSL and exchanges date via ATM with the DSLAM at the CO. HARDWARE ENVIRONMENT * Normal Intel Based PC * Ethernet Card * Netopia DSL Router OS * Stock distribute of "Woody" Debian Linux. (i.e. Release 2.2.17 ) -- Paul Romero RCOM Communications Software Phone/Fax: (510)339-2628 E-Mail: paulr@rcom-software.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i57LjKvM005557; Mon, 7 Jun 2004 14:45:20 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i57LjKwV005556; Mon, 7 Jun 2004 14:45:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i57LjJ7O005549 for ; Mon, 7 Jun 2004 14:45:19 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 32057151F18; Mon, 7 Jun 2004 17:45:23 -0400 (EDT) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: Use of NFKC in SASLprep References: <6.0.1.1.0.20040603232331.049a3188@127.0.0.1> From: Sam Hartman Date: Mon, 07 Jun 2004 17:45:23 -0400 In-Reply-To: (Simon Josefsson's message of "Sat, 05 Jun 2004 14:19:48 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) 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: >>>>> "Simon" == Simon Josefsson writes: Simon> appears to make SASLPrep2 more complicated to specify Simon> (since SASLprep is not idempotent), with consequences for Simon> SASL user database migration (if prepared strings are Simon> stored in the database, which I have suggested shouldn't be Simon> the case in another thread). As someone who tends to believe that prepared strings should be stored in the database, I think it is worth working through the issues of what we will do with saslprep2 now. My presumption is that we go forward assuming that saslprep is idempotent even though we know it is not. That is, we ignore this issue now and for all future versions of saslprep. --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i56AKCsk032750; Sun, 6 Jun 2004 03:20:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i56AKCWH032749; Sun, 6 Jun 2004 03:20:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i56AK7up032741 for ; Sun, 6 Jun 2004 03:20:08 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BWul6-0000M3-00 for ; Sun, 06 Jun 2004 12:20:08 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 06 Jun 2004 12:20:08 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 06 Jun 2004 12:20:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Use of NFKC in SASLprep Date: Sun, 06 Jun 2004 12:20:03 +0200 Lines: 25 Message-ID: References: <6.0.1.1.0.20040603232331.049a3188@127.0.0.1> <40110000.1086482386@mariner.pc.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:RZeeepijxtJ6QM25COpKhxxPWz4= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman writes: > There is not a problem with NFKC. There is a TYPO in the document > which specifies it. If NFKC is implemented correctly, as is done by > multiple implementations _including the sample implementation in the > same document_, there is no problem. I spoke to other implementors of StringPrep, which do implement NFKC the same way as the reference implementation (i.e., not according to the letter of the specification), and one of the Stringprep authors had told them that then they were simply not following the current specifications. I think a public statement committing to one of the two interpretation (i.e., either consider it a typo in the old version of NFKC, or that the typo corrected NFKC will be a new version, which StringPrep doesn't use yet) of this problem would be useful. > In the meantime, because SASLprep will be used in security-sensitive > applications including SASL and Kerberos, I think it is appropriate to > include a reference to PR-29 and a recommendation that implementors > insure that NFKC is implemented correctly. We agree about this. Thanks, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i560eD5X076741; Sat, 5 Jun 2004 17:40:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i560eDto076739; Sat, 5 Jun 2004 17:40:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mariner.pc.cs.cmu.edu (dsl093-061-085.pit1.dsl.speakeasy.net [66.93.61.85]) by above.proper.com (8.12.11/8.12.9) with SMTP id i560eAwx076729 for ; Sat, 5 Jun 2004 17:40:10 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa31514; 5 Jun 2004 20:39 EDT Date: Sat, 05 Jun 2004 20:39:46 -0400 From: Jeffrey Hutzelman To: Simon Josefsson , ietf-sasl@imc.org Subject: Re: Use of NFKC in SASLprep Message-ID: <40110000.1086482386@mariner.pc.cs.cmu.edu> In-Reply-To: References: <6.0.1.1.0.20040603232331.049a3188@127.0.0.1> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Saturday, June 05, 2004 14:19:48 +0200 Simon Josefsson wrote: > So, what do we have here? There is a known specification ambiguity in > NFKC that, for example, appear to allow implementations to return > three distinct output from the input string U+0B47 U+0300 U+0B3E > U+0323 (see earlier discussion). This is an interoperability problem. > It appears to make SASLPrep2 more complicated to specify (since > SASLprep is not idempotent), with consequences for SASL user database > migration (if prepared strings are stored in the database, which I > have suggested shouldn't be the case in another thread). It is > difficult to see that this property is impossible to abuse when > attacking systems that use SASLprep on authentication/authorization > tokens. And the conclusion? Let's ignore the issue, and make sure it > is not even mentioned. It strikes me that people are blowing this way out of proportion, and I really dislike the repeated attempts in this working group to "fix" Unicode, which is _way way way_ out of scope for us. There is not a problem with NFKC. There is a TYPO in the document which specifies it. If NFKC is implemented correctly, as is done by multiple implementations _including the sample implementation in the same document_, there is no problem. This is not the end of the world. We've certainly had similar problems in IETF documents; the RFC Editor has a long list of errata for published RFC's. I cannot imagine that the Unicode Consortium will not publish a corrigendum to correct the erroneous document. In the meantime, because SASLprep will be used in security-sensitive applications including SASL and Kerberos, I think it is appropriate to include a reference to PR-29 and a recommendation that implementors insure that NFKC is implemented correctly. I do _not_ think it is appropriate to suggest behaviour _other_ than simply implementing NFKC correctly. For example, I don't think it's appropriate to specify that a large class of sequences be prohibited from output. Any implementation which would be in a position to implement such a suggestion is _also_ in a position to get NFKC right in the first place, thereby avoiding the entire problem. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i55CK2u5088727; Sat, 5 Jun 2004 05:20:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i55CK2Y7088726; Sat, 5 Jun 2004 05:20:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i55CJvWM088704 for ; Sat, 5 Jun 2004 05:19:58 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BWa9U-00048X-00 for ; Sat, 05 Jun 2004 14:19:56 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 05 Jun 2004 14:19:56 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 05 Jun 2004 14:19:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Use of NFKC in SASLprep Date: Sat, 05 Jun 2004 14:19:48 +0200 Lines: 70 Message-ID: References: <6.0.1.1.0.20040603232331.049a3188@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:/eeEHBfvkEPyendj6K8TeUuxiQQ= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > We also had a discussion as to wether the SASLprep I-D should > note the existence of this issue (without any fix) and its > impact upon implementations (and use) of SASLprep. They argued > that such would be inappropriate for SASLprep I-D to include > such as there no issue specific to the SASLprep profile of > Stringprep here. So, what do we have here? There is a known specification ambiguity in NFKC that, for example, appear to allow implementations to return three distinct output from the input string U+0B47 U+0300 U+0B3E U+0323 (see earlier discussion). This is an interoperability problem. It appears to make SASLPrep2 more complicated to specify (since SASLprep is not idempotent), with consequences for SASL user database migration (if prepared strings are stored in the database, which I have suggested shouldn't be the case in another thread). It is difficult to see that this property is impossible to abuse when attacking systems that use SASLprep on authentication/authorization tokens. And the conclusion? Let's ignore the issue, and make sure it is not even mentioned. Speaking as an implementor, I hesitate to expose my users to this issue. The conservative approach appear to be to enforce, in the implementation, a local policy of rejecting the ambiguous input strings directly. This remove the need to worry about this issue, without any obvious negative consequences (correct me if I'm wrong). Applying the same conservative approach to the specification seem possible. The drawback of doing so? We have to describe how implementions should detect and reject the ambiguous combination of code points. The advantage? Implementors aren't exposed to interoperability and security issues. Further, migrating to SASLprep2 may be simpler since it is more likely to be able to assume SASLprep is idempotent. Below is a proposal for this section, and I hope it can be considered. If the text, or something similar to it, is not adopted, I feel that at least acknowledging the issue would be appropriate. The ambiguity in NFKC doesn't disappear even if you refuse to acknowledge it. What do other implementors think? Have you compared the NFKC implementation you use with the test vectors in PR-29? Thanks, Simon 2.3.1 Prohibited Output Of Problem Sequences The algorithm used by [StringPrep] to normalize sequences have been discovered [PR-29] to be non-idempotent. Fortunately, this appear to only affect a restricted set of combination of code points, and none of those combinations are believed to occur naturally (due to different linguistic uses of the characters). Idempotency of the SASLprep operation is important for interoperability, security, and migration to revised versions of SASLprep. Thus, this section prohibit the problem sequences from occurring in SASLprep output. The logic to detect and prohibit the problem sequences uses the tables from [PR-29]. The problem sequences begin with a code point from one row in column 1 of table 1, followed by one or more of the 163 code points with a non-zero Canonical Combination Class (see Table 2), followed by one of the code points in the same row, in column 2 of Table, corresponding to the row of the first code point. [Table 1 is table 2 from .] [Table 2 is the non-zero entries of ] Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54FuGp8037722; Fri, 4 Jun 2004 08:56:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i54FuGAF037721; Fri, 4 Jun 2004 08:56:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54FuE5X037710 for ; Fri, 4 Jun 2004 08:56:14 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i54Fswqf045171; Fri, 4 Jun 2004 15:55:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040603232331.049a3188@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 04 Jun 2004 08:54:54 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: Use of NFKC in SASLprep Cc: ietf-sasl@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i54FuF5X037716 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 04:19 PM 4/22/2004, Simon Josefsson wrote: >FYI, as SASLprep is using NFKC per Unicode 3.2, you might be >interested in the NFKC stability problem discussed on >. The page mention a >strategy to maintain stability across NFKC revisions, which might be >relevant for SASLPrep. I'd be interested to hear people's opinions on >the problem. I recently consulted with authors of [Stringprep] (namely Paul Hoffman) as well as our liaison to the UTC (Patrik Fältström) regarding this [SASLprep] concern. They recommend that the SASLprep I-D not attempt to fix the issue discussed in PR#29. They argue (as I understand their arguments) that it would be inappropriate for SASLprep, a profile of Stringprep, to apply PR#29 to a version of Unicode instead of utilize Unicode normalization as required by Stringprep. Or, to say it in another way, PR#29 issues in a consistent manner for all profiles of Stringprep and hence ought to be handled as part of the ongoing revision of Stringprep (and its normative references). They suggest we not wait for this revision. I fully support with their recommendation (which is consistent with my prior recommendations to the WG). We also had a discussion as to wether the SASLprep I-D should note the existence of this issue (without any fix) and its impact upon implementations (and use) of SASLprep. They argued that such would be inappropriate for SASLprep I-D to include such as there no issue specific to the SASLprep profile of Stringprep here. They noted it **might** be appropriate to publish an Informational RFC updating [Stringprep]. While I have some mild reservations, I can support this recommendation. Please consider these recommendations. Sam (as chair) and I (as editor) intend to response to the IESG comment regarding concern within the next week. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53HKv8H003905; Thu, 3 Jun 2004 10:20:57 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i53HKvt4003904; Thu, 3 Jun 2004 10:20:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fe.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53HKu5f003880; Thu, 3 Jun 2004 10:20:56 -0700 (PDT) (envelope-from paulr@rcom-software.com) Received: from [64.139.27.223] (HELO rcom-software.com) by fe.mail.megapathdsl.net (CommuniGate Pro SMTP 4.1.8) with ESMTP id 172482636; Thu, 03 Jun 2004 10:20:54 -0700 Message-ID: <40BF5E34.97B4473B@rcom-software.com> Date: Thu, 03 Jun 2004 10:21:56 -0700 From: Paul Romero Organization: RCOM Communications Software X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en,es,de-DE,fr-FR MIME-Version: 1.0 To: ietf-sasl@imc.org, phoffman@imc.org Subject: Use of AUTH with SMTP 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: Dear SASL User Group Can anybody provide some insight into the following questions about how the AUTH mechanism is used with SMTP ? 1) How commonly deployed is the AUTH mechanism--as described in RFC 2554--in commercial ISP SMTP implementations ? 2) Is the CRAM-MD5 variant normally used ? If not, which others are commonly used ? 3) Is the AUTH mechanism usually implemented on a stand alone basis or in conjunction with other service--for instance TLS ? 3.1) If it is implemented with other services, what are the relevant RFCs ? Best Regards, Paul Romero -- Paul Romero RCOM Communications Software Phone/Fax: (510)339-2628 E-Mail: paulr@rcom-software.com