From owner-ietf-sasl Sat May 1 03:43:17 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 i41AhHmM031706; Sat, 1 May 2004 03:43:17 -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 i41AhHdR031705; Sat, 1 May 2004 03:43:17 -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 i41AhCir031679 for ; Sat, 1 May 2004 03:43:13 -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 1BJrxh-00058s-00 for ; Sat, 01 May 2004 12:43:13 +0200 Received: from h21n4c2o273.bredband.skanova.com ([217.208.171.21]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 May 2004 12:43:13 +0200 Received: from jas by h21n4c2o273.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 May 2004 12:43:13 +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, 01 May 2004 12:43:06 +0200 Lines: 30 Message-ID: References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@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: h21n4c2o273.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:aYmeBz67Vuc+LT3AMpIgsaRxGZI= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > It's my opinion that that this issue, aside from noting its > existence, should be addressed in NFKC by the UTC, then in > Stringprep by the IETF, and lastly in SASLprep by this WG. > But we shouldn't wait for this, we should publish what we > have as being "good enough" and then revise once the upstream > specifications have been appropriately revised. Without qualifying this, this means abandoning the invariant SASLprep2(SASLprep(X)) = SASLprep(X), and given the details of PR-29 even abandoning SASLprep(SASLprep(X)) = SASLprep(X), in a few cases. In an earlier discussion about SASLprep the argument was, as far as I can recall, that my proposed text regarding storing SASLprep strings in databases was not needed, because the invariant was implied by other specifications. I just hope everyone pushing this forward is able to visualize the entire long-term puzzle, as I know I'm having difficulties with the SASLprep piece. Another comment on PR-29: it may be that the problematic INPUT code points to NFKC do not occur naturally, but as far as security is concerned there is another question: the OUTPUT code points must also not occur naturally. Otherwise, someone may be able to use "unnatural" code points to bypass the first security perimeter, and have the input changed (NFKC) into some "natural" code point once inside the security system. Also, simply having NFKC(NFKC(x)) != NFKC(x) may generate weird corner cases that could be exploited. Thanks, Simon From owner-ietf-sasl Sat May 1 07:49:11 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 i41EnBuG063968; Sat, 1 May 2004 07:49:11 -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 i41EnBID063967; Sat, 1 May 2004 07:49:11 -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 i41En8Hs063960 for ; Sat, 1 May 2004 07:49:08 -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.10) with ESMTP id i41En1aQ003497; Sat, 1 May 2004 14:49:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040501074352.02c63750@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 01 May 2004 07:48:57 -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.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@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: Simon, As you don't appear to support my suggestion, I wonder alternative you suggest we undertake. Wait? Kurt At 03:43 AM 5/1/2004, Simon Josefsson wrote: >"Kurt D. Zeilenga" writes: > >> It's my opinion that that this issue, aside from noting its >> existence, should be addressed in NFKC by the UTC, then in >> Stringprep by the IETF, and lastly in SASLprep by this WG. >> But we shouldn't wait for this, we should publish what we >> have as being "good enough" and then revise once the upstream >> specifications have been appropriately revised. > >Without qualifying this, this means abandoning the invariant >SASLprep2(SASLprep(X)) = SASLprep(X), and given the details of PR-29 >even abandoning SASLprep(SASLprep(X)) = SASLprep(X), in a few cases. >In an earlier discussion about SASLprep the argument was, as far as I >can recall, that my proposed text regarding storing SASLprep strings >in databases was not needed, because the invariant was implied by >other specifications. I just hope everyone pushing this forward is >able to visualize the entire long-term puzzle, as I know I'm having >difficulties with the SASLprep piece. > >Another comment on PR-29: it may be that the problematic INPUT code >points to NFKC do not occur naturally, but as far as security is >concerned there is another question: the OUTPUT code points must also >not occur naturally. Otherwise, someone may be able to use >"unnatural" code points to bypass the first security perimeter, and >have the input changed (NFKC) into some "natural" code point once >inside the security system. Also, simply having NFKC(NFKC(x)) != >NFKC(x) may generate weird corner cases that could be exploited. > >Thanks, >Simon From owner-ietf-sasl Sat May 1 09:56: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 i41Gu4kY077955; Sat, 1 May 2004 09:56: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 i41Gu4o5077954; Sat, 1 May 2004 09:56:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i41Gu0Fi077945 for ; Sat, 1 May 2004 09:56:04 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.11/8.12.11) with ESMTP id i41Gu01a008562 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 1 May 2004 18:56:00 +0200 To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: Use of NFKC in SASLprep References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@127.0.0.1> <6.0.1.1.0.20040501074352.02c63750@127.0.0.1> From: Simon Josefsson X-Hashcash: 0:040501:Kurt@OpenLDAP.org:06990d28147292b4 X-Hashcash: 0:040501:ietf-sasl@imc.org:25b9749496d2168a Date: Sat, 01 May 2004 18:55:55 +0200 In-Reply-To: <6.0.1.1.0.20040501074352.02c63750@127.0.0.1> (Kurt D. Zeilenga's message of "Sat, 01 May 2004 07:48:57 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (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: "Kurt D. Zeilenga" writes: > Simon, > > As you don't appear to support my suggestion, I wonder > alternative you suggest we undertake. Wait? Short term: Evaluate the completeness of the problem sequences described in PR-29, and prohibit them in SASLprep output. As I understand it, this would be sufficient to make SASLprep idempotent. A system where the user identifiers change several times after repeated use of SASLprep, i.e. non-idempotent SASLprep, is not robust and is difficult to analyze. Medium term: Describe the usage of SASLprep in detail. If necessary, it might be possible to do this even after the actual SASLprep algorithm has been published. If the invariant SASLPrep2(SASLprep(X))=SASLPrep2(X) is not written into SASLprep as a commitment to the future, I'd like to open the question of not using the AllowUnassigned flag, as removing it would simplify the SASLprep usage. It is a telling sign that, as far as I can tell, none of the current SASL mechanism documents discuss when to set the flag. If removal isn't an option, the use of the flag should be discussed in the documents. Long term: Write a requirements document based on the non-technical needs internationalized users have, and implement a solution to those requirements. My impression is that SASLprep has been driven by technical goals, with a world view centered around a StringPrep solution from the start. Hope this helps, Simon From owner-ietf-sasl Sat May 1 11:33:09 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 i41IX9ZG084116; Sat, 1 May 2004 11:33:09 -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 i41IX9DE084115; Sat, 1 May 2004 11:33:09 -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 i41IX6V6084099 for ; Sat, 1 May 2004 11:33:06 -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.10) with ESMTP id i41IWvaQ005228; Sat, 1 May 2004 18:33:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040501112553.02c86970@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 01 May 2004 11:32:53 -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.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@127.0.0.1> <6.0.1.1.0.20040501074352.02c63750@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 09:55 AM 5/1/2004, Simon Josefsson wrote: >"Kurt D. Zeilenga" writes: >> Simon, >> As you don't appear to support my suggestion, I wonder >> alternative you suggest we undertake. Wait? > >Short term: Evaluate the completeness of the problem sequences >described in PR-29, I rather leave that to the UTC. >and prohibit them in SASLprep output. How? Stringprep prohibit step is designed to prohibit on a per code point basis. We'd effectively have to design a new prohibit step for the algorithm. Why should that be done in a SASLprep-specific manner? If the most appropriate thing to do is prohibit certain sequences in the short term, wouldn't it make better sense to update stringprep so that all stringprep profiles do it in a like way? Kurt From owner-ietf-sasl Sat May 1 12:04: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 i41J4CbS090540; Sat, 1 May 2004 12:04: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 i41J4CDf090539; Sat, 1 May 2004 12:04: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 i41J48KE090532 for ; Sat, 1 May 2004 12:04:09 -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 1BJzmR-0002WS-00 for ; Sat, 01 May 2004 21:04:07 +0200 Received: from h21n4c2o273.bredband.skanova.com ([217.208.171.21]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 May 2004 21:04:07 +0200 Received: from jas by h21n4c2o273.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 May 2004 21:04:07 +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, 01 May 2004 21:04:00 +0200 Lines: 27 Message-ID: References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@127.0.0.1> <6.0.1.1.0.20040501074352.02c63750@127.0.0.1> <6.0.1.1.0.20040501112553.02c86970@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: h21n4c2o273.bredband.skanova.com User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:aZnUrIp1XQoTPAqW1TmvDkT8NIQ= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: >>and prohibit them in SASLprep output. > > How? Stringprep prohibit step is designed to prohibit on > a per code point basis. We'd effectively have to design > a new prohibit step for the algorithm. Right. > Why should that be done in a SASLprep-specific manner? If the most > appropriate thing to do is prohibit certain sequences in the short > term, wouldn't it make better sense to update stringprep so that all > stringprep profiles do it in a like way? I'm not sure. It is conceivable that what makes sense for SASLprep does not make sense for Stringprep in general. If the authors responsible for the Stringprep revision think what you propose makes sense, then I would agree. (I wouldn't call that a short term solution, though.) But if not, and if they don't have another solution in mind, I believe idempotency is important enough, for security reasons, that SASLprep should fixed, instead of being published as-is. I'm told the Stringprep authors are preparing a statement on this issue, though, which might give other alternatives. Thanks, Simon From owner-ietf-sasl Sun May 2 08:30:49 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 i42FUnBv022333; Sun, 2 May 2004 08:30:49 -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 i42FUnlV022332; Sun, 2 May 2004 08:30:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.59.238]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i42FUm9j022325 for ; Sun, 2 May 2004 08:30:49 -0700 (PDT) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i42FUoal023892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 2 May 2004 11:30:51 -0400 (EDT) Message-ID: <409514AC.9040404@columbia.edu> Date: Sun, 02 May 2004 11:33:00 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: Use of NFKC in SASLprep References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@127.0.0.1> <6.0.1.1.0.20040501074352.02c63750@127.0.0.1> <6.0.1.1.0.20040501112553.02c86970@127.0.0.1> In-Reply-To: <6.0.1.1.0.20040501112553.02c86970@127.0.0.1> Content-Type: multipart/alternative; boundary="------------020601000203090405030703" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------020601000203090405030703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >>and prohibit them in SASLprep output. >> > >How? Stringprep prohibit step is designed to prohibit on >a per code point basis. We'd effectively have to design >a new prohibit step for the algorithm. Why should that be >done in a SASLprep-specific manner? If the most appropriate >thing to do is prohibit certain sequences in the short term, >wouldn't it make better sense to update stringprep so that >all stringprep profiles do it in a like way? > >Kurt > Has anyone asked the authors of StringPrep their opinion? Clearly this problem needs to be addressed not in SASLPrep but in a revision to StringPrep as it affects all profiles based on StringPrep. Modifying SASLPrep will only cause more problems if the solution adopted for StringPrep is incompatible. Jeffrey Altman --------------020601000203090405030703 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: 
and prohibit them in SASLprep output.


How?  Stringprep prohibit step is designed to prohibit on
a per code point basis.  We'd effectively have to design
a new prohibit step for the algorithm.  Why should that be
done in a SASLprep-specific manner?  If the most appropriate
thing to do is prohibit certain sequences in the short term,
wouldn't it make better sense to update stringprep so that
all stringprep profiles do it in a like way?

Kurt
Has anyone asked the authors of StringPrep their opinion?

Clearly this problem needs to be addressed not in SASLPrep
but in a revision to StringPrep as it affects all profiles
based on StringPrep.  Modifying SASLPrep will only cause
more problems if the solution adopted for StringPrep is
incompatible.

Jeffrey Altman


--------------020601000203090405030703-- From owner-ietf-sasl Mon May 3 10:50: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 i43HoGUK041892; Mon, 3 May 2004 10:50: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 i43HoGjF041891; Mon, 3 May 2004 10:50:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i43HoGJl041862 for ; Mon, 3 May 2004 10:50:16 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i43Ho46b026887; Mon, 3 May 2004 10:50:04 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i43Ho44F023163; Mon, 3 May 2004 11:50:04 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i43HnQhf010806; Mon, 3 May 2004 12:49:26 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i43HnPFO010805; Mon, 3 May 2004 12:49:25 -0500 (CDT) Date: Mon, 3 May 2004 12:49:24 -0500 From: Nicolas Williams To: Jeffrey Altman Cc: ietf-sasl@imc.org Subject: Re: Use of NFKC in SASLprep Message-ID: <20040503174924.GO9637@binky.central.sun.com> Mail-Followup-To: Jeffrey Altman , ietf-sasl@imc.org References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@127.0.0.1> <6.0.1.1.0.20040501074352.02c63750@127.0.0.1> <6.0.1.1.0.20040501112553.02c86970@127.0.0.1> <409514AC.9040404@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <409514AC.9040404@columbia.edu> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, May 02, 2004 at 11:33:00AM -0400, Jeffrey Altman wrote: > Has anyone asked the authors of StringPrep their opinion? > > Clearly this problem needs to be addressed not in SASLPrep > but in a revision to StringPrep as it affects all profiles > based on StringPrep. Modifying SASLPrep will only cause > more problems if the solution adopted for StringPrep is > incompatible. My take is that this is easy to fix in Unicode itself, as per-the recommendations in pr-29, in part because there exist Unicode implementations which do not have this problem and some that do and there's no better place to fix this than in Unicode where all downstream consumers of NFKC would benefit automatically. But see below. We have: - UAX #15 is internally inconsistent, - the inconsistency results in NFKC(NFKC(x) != NFKC(x) - but only for rather unrealistic instances of 'x' - which, nonetheless should cause us some concern - But some implementations don't have this problem, - and the fix to UAX #15 seems rather simple (but it's possible that there's more than meets the untrained eye...) All of which makes me think that Unicode is the right place to fix the problem and that we should wait for the Unicode consortium to issue a corrigendum or other statement before doing much of anything about this. Until then a security considerations warning about the troublesome input sequences ought to suffice, methinks. Mor importantly, rather than discuss this matter at the SASL or KRB or any other IETF WG I'd prefer to see this discussed more broadly and, if possible, get some input from the relevant area directors. Perhaps this matter should be taken up with the IETF liason to the Unicode consortium. Cheers, Nico -- From owner-ietf-sasl Mon May 3 14:06:47 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 i43L6lEC084210; Mon, 3 May 2004 14:06:47 -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 i43L6l6A084209; Mon, 3 May 2004 14:06:47 -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 i43L6iXm084200 for ; Mon, 3 May 2004 14:06:44 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 753A1151D5C; Mon, 3 May 2004 17:06:45 -0400 (EDT) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: Use of NFKC in SASLprep References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@127.0.0.1> From: Sam Hartman Date: Mon, 03 May 2004 17:06:45 -0400 In-Reply-To: (Simon Josefsson's message of "Sat, 01 May 2004 12:43:06 +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> "Kurt D. Zeilenga" writes: >> It's my opinion that that this issue, aside from noting its >> existence, should be addressed in NFKC by the UTC, then in >> Stringprep by the IETF, and lastly in SASLprep by this WG. But >> we shouldn't wait for this, we should publish what we have as >> being "good enough" and then revise once the upstream >> specifications have been appropriately revised. Simon> Without qualifying this, this means abandoning the Simon> invariant SASLprep2(SASLprep(X)) = SASLprep(X), and given Simon> the details of PR-29 even abandoning SASLprep(SASLprep(X)) Simon> = SASLprep(X), in a few cases. In an earlier discussion Simon> about SASLprep the argument was, as far as I can recall, Simon> that my proposed text regarding storing SASLprep strings in Simon> databases was not needed, because the invariant was implied Simon> by other specifications. I think the invariant is implied and that it is our job to assume the invariant shall be maintained regardless of whether it actually is. We should make sure the authors of stringprep know we're going forward with the assumption of this invariant and agree doing so is the right course of action. If we ever violate this invariant we should do so with the understanding that the practical consequences of assuming the invariant and violating it in the manner we actually violate it are acceptable. Another point to consider regarding this issue: the IDN working group set an interesting precedent by choosing not to correct UNicode bugs in their working group. They decided they were not qualified to do so and the IETF was not the appropriate forum. If we choose to take a different course of action, we should have strong justification for why their reasoning does not apply to our circumstance. --Sam From owner-ietf-sasl Wed May 19 16:29:58 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 i4JNTvE1078767; Wed, 19 May 2004 16:29: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 i4JNTvB5078766; Wed, 19 May 2004 16:29:57 -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 i4JNTq65078758 for ; Wed, 19 May 2004 16:29:54 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust188.tnt5.lnd4.gbr.da.uu.net [62.188.134.188]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 20 May 2004 00:29:43 +0100 Message-ID: <40ABCB09.4080102@isode.com> Date: Wed, 19 May 2004 22:00:57 +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 , Rob Siemborski Subject: Pending changes to the base SASL document 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: I am waiting for resolution on one final issue before issuing a new revision of rfc2222bis that should be ready for Last Call. Plus I have 2 minor new issues with suggested text. 1). empty versa missing additional data with success (text in 2 places). Add to Section 4. ("Protocol profile requirements"): "Note that SASL treats an empty additional data with success notification as equivalent to no additional data with success notification. If the protocol allows for the additional data with success notification, the empty additional data SHOULD NOT be used, unless dictated otherwise by the protocol profile." I am actually not sure myself about the last sentence. Should the document just say that an empty additional data with success is prohibited? Add to Section 5. ("Mechanism profile guidelines"): "As SASL treats an empty additional data with success notification as equivalent to no additional data with success notification, mechanisms that may distinguish between no additional data and empty additional data MUST use some encoding or escape mechanism when sending data semantically equivalent to the empty additional data with success." The last sentence is awkward at best, any suggestions would be appreciated. Currently there is no SASL mechanism that make such distinction, but, IMHO, the warning should be added. ===== New issues: 2). Servers need to perform profile specific mapping from a mechanism specific authorization identity to profile specific form. The profile specific form is used internally by the server (for example for logging), but can often be used by the protocol for access control. In order for the client to determine the result of any such mapping, the protocol should have a command or option to return it to the client. For example, LDAP has 2 ways to achieve this: "Who am I" extended operation and a control that can request for mapping information to be returned upon successful authentication. I felt that this is a feature common to all protocols, and thus should be mentions in the base SASL document. Kurt suggested the following text for addition to Section 4. ("Protocol profile requirements"): Where the application-layer protocol does not precisely state how identities established through SASL relate to identities used elsewhere (e.g., access controls) in the application-layer protocol, it may be useful for the application-layer protocol to provide a facility which the client may use to discover the identity used. Any objections? 3). Some people are complaining that some SASL mechanisms use too many roundtrips. This is a performance penalty for protocols like HTTP, where the client can reconnect multiple times. Currently only DIGEST-MD5 and SRP have support for fast reautentication. So, I would like to add the following requirement to Section 5. ("Mechanism profile guidelines"). Please, let me know if you agree or disagree. Suggested text: "SASL mechanisms SHOULD support fast reauthentication, if practical." Alexey From owner-ietf-sasl Thu May 20 09:42:07 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 i4KGg7Hs090646; Thu, 20 May 2004 09:42:07 -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 i4KGg7bX090645; Thu, 20 May 2004 09:42:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.83]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4KGg6RE090639 for ; Thu, 20 May 2004 09:42:06 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4KGg7Y8032173; Thu, 20 May 2004 12:42:07 -0400 Date: Thu, 20 May 2004 12:42:06 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <40ABCB09.4080102@isode.com> Message-ID: References: <40ABCB09.4080102@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 19 May 2004, Alexey Melnikov wrote: > 3). Some people are complaining that some SASL mechanisms use too many > roundtrips. This is a performance penalty for protocols like HTTP, where the > client can reconnect multiple times. Currently only DIGEST-MD5 and SRP have > support for fast reautentication. So, I would like to add the following > requirement to Section 5. ("Mechanism profile guidelines"). Please, let me > know if you agree or disagree. > Suggested text: > > "SASL mechanisms SHOULD support fast reauthentication, if practical." Given our limited experience with actual deployment of fast reauthentication mechanisms (Has anyone actually tested any sort of interoperability of DIGEST-MD5 fast reauth?), I wouldn't want us to give the impression that a mechanism that does not support fast reauthentication is somehow less than fully compliant (yeah, ok, it is only a SHOULD). If there's a demand for mechanisms that support fast reauth, then those mechanisms will be written and implemented widely. Currently, that isn't the case, and I don't see a reason why the base document needs to pass judgment on the matter. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Thu May 20 11:05: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 i4KI5FvI097459; Thu, 20 May 2004 11:05:15 -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 i4KI5Fs1097458; Thu, 20 May 2004 11:05:15 -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 i4KI5Fw6097452 for ; Thu, 20 May 2004 11:05:15 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 31112151D5C; Thu, 20 May 2004 14:05:18 -0400 (EDT) To: Alexey Melnikov Cc: SASL WG , Rob Siemborski Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> From: Sam Hartman Date: Thu, 20 May 2004 14:05:17 -0400 In-Reply-To: <40ABCB09.4080102@isode.com> (Alexey Melnikov's message of "Wed, 19 May 2004 22:00:57 +0100") 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: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> "SASL mechanisms SHOULD support fast reauthentication, Alexey> if practical." Alexey> Alexey I don't like this text because it is not even clear what it means. How about: SASL mechanisms should be designed to minimize the number of round trips required because SASL is used with protocols where connections are short-lived. As a side note, has thought been given in the HTTP case to having mechanisms for reusing SASL contexts across connections? From owner-ietf-sasl Fri May 21 02:25:31 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 i4L9PV3K006513; Fri, 21 May 2004 02:25:31 -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 i4L9PV1m006512; Fri, 21 May 2004 02:25:31 -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 i4L9PUdc006499 for ; Fri, 21 May 2004 02:25:30 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust202.tnt28.lnd4.gbr.da.uu.net [62.188.156.202]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Fri, 21 May 2004 10:25:23 +0100 Message-ID: <40AD19AA.8050601@isode.com> Date: Thu, 20 May 2004 21:48:42 +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: Sam Hartman CC: SASL WG , Rob Siemborski Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> In-Reply-To: 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: Sam Hartman wrote: >>>>>> >>>>>> >>>>>> > > Alexey> "SASL mechanisms SHOULD support fast reauthentication, > Alexey> if practical." > > Alexey> Alexey > > > > > >I don't like this text because it is not even clear what it means. > >How about: > >SASL mechanisms should be designed to minimize the number of round >trips required because SASL is used with protocols where connections >are short-lived. > Ok, that sounds better. But I will change "SASL is used" to "SASL may be used". > > >As a side note, has thought been given in the HTTP case to having >mechanisms for reusing SASL contexts across connections? > > Well, I thought about that, this is one of the reasons why I've proposed that the sentence is added. But I am not sure I have a firm opinion on how this will be done. IMHO, DIGEST-MD5 fast reauth mode can be used accross multiple connections, because the client IP is not used in the authentication exchange. I am also contemplating about writing an extension to the GSSAPI mechanism to allow for fast reauth in 1 round trip. Alexey From owner-ietf-sasl Fri May 21 02:25: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 i4L9P4TA006295; Fri, 21 May 2004 02:25: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 i4L9P4Qs006294; Fri, 21 May 2004 02:25:04 -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 i4L9P3Tc006200 for ; Fri, 21 May 2004 02:25:03 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust202.tnt28.lnd4.gbr.da.uu.net [62.188.156.202]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Fri, 21 May 2004 10:24:51 +0100 Message-ID: <40AD17D5.5030109@isode.com> Date: Thu, 20 May 2004 21:40:53 +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: Rob Siemborski CC: SASL WG Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> In-Reply-To: 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 Wed, 19 May 2004, Alexey Melnikov wrote: > >> 3). Some people are complaining that some SASL mechanisms use too >> many roundtrips. This is a performance penalty for protocols like >> HTTP, where the client can reconnect multiple times. Currently only >> DIGEST-MD5 and SRP have support for fast reautentication. So, I would >> like to add the following requirement to Section 5. ("Mechanism >> profile guidelines"). Please, let me know if you agree or disagree. >> Suggested text: >> >> "SASL mechanisms SHOULD support fast reauthentication, if practical." > > > Given our limited experience with actual deployment of fast > reauthentication mechanisms (Has anyone actually tested any sort of > interoperability of DIGEST-MD5 fast reauth?), I wouldn't want us to > give the impression that a mechanism that does not support fast > reauthentication is somehow less than fully compliant (yeah, ok, it is > only a SHOULD). > > If there's a demand for mechanisms that support fast reauth, then > those mechanisms will be written and implemented widely. Currently, > that isn't the case, and I don't see a reason why the base document > needs to pass judgment on the matter. Ok, this is a fair argument against the suggested text. Alexey P.S. You haven't answered the most difficult question (# 1). As you are the one who has raised the original objection, I would like to hear your comments. From owner-ietf-sasl Fri May 21 06:03: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 i4LD3gS5064068; Fri, 21 May 2004 06:03: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 i4LD3fBN064067; Fri, 21 May 2004 06:03:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LD3e52064053 for ; Fri, 21 May 2004 06:03:41 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id B52A276662; Fri, 21 May 2004 09:04:10 -0400 (EDT) To: Alexey Melnikov Cc: SASL WG , Rob Siemborski Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> <40AD19AA.8050601@isode.com> From: Sam Hartman Date: Fri, 21 May 2004 09:04:10 -0400 In-Reply-To: <40AD19AA.8050601@isode.com> (Alexey Melnikov's message of "Thu, 20 May 2004 21:48:42 +0100") Message-ID: <87smdu53ud.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (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: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> I am also contemplating about writing an extension to the Alexey> GSSAPI mechanism to allow for fast reauth in 1 round trip. I believe you can just remove a half round trip from the GSSAPI all the time by combining the security layer stuff with the last token. From owner-ietf-sasl Fri May 21 06:35: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 i4LDZ4Vi071116; Fri, 21 May 2004 06:35: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 i4LDZ48g071115; Fri, 21 May 2004 06:35:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LDZ3pV071101 for ; Fri, 21 May 2004 06:35:03 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LDZ5af018564; Fri, 21 May 2004 09:35:05 -0400 Date: Fri, 21 May 2004 09:35:05 -0400 (EDT) From: Rob Siemborski To: Sam Hartman cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: Message-ID: References: <40ABCB09.4080102@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 20 May 2004, Sam Hartman wrote: > How about: > > SASL mechanisms should be designed to minimize the number of round > trips required because SASL is used with protocols where connections > are short-lived. I like this text more (especially the use of 'should' instead of SHOULD), but I'm still unclear why the base document needs to say anything at all about it. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Fri May 21 06:39:06 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 i4LDd6hf072325; Fri, 21 May 2004 06:39:06 -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 i4LDd6Oh072324; Fri, 21 May 2004 06:39:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LDd5Bn072314 for ; Fri, 21 May 2004 06:39:06 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LDd60s019022; Fri, 21 May 2004 09:39:06 -0400 Date: Fri, 21 May 2004 09:39:07 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <40AD17D5.5030109@isode.com> Message-ID: References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 20 May 2004, Alexey Melnikov wrote: > P.S. You haven't answered the most difficult question (# 1). As you are the > one who has raised the original objection, I would like to hear your > comments. Do we really need to make lack-of-response equivilent with the empty response? It seems we can handle this cleanly enough if we treat it just like the initial response. e.g. If the protocol allows for the initial response, the protocol profile SHOULD also describe how an empty initial response is encoded. could be worded as If the protocol allows for optional data to be sent with success notifiation, the protocol profile SHOULD also describe how empty success data is encoded. later on in Section 4. Forbidding empty success data makes me less happy (its less flexible), but I think its better than defining "no data" as equivilent to "the empty string was sent". -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Fri May 21 07:08:47 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 i4LE8llC078198; Fri, 21 May 2004 07:08:47 -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 i4LE8lwx078197; Fri, 21 May 2004 07:08:47 -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 i4LE8jpT078185 for ; Fri, 21 May 2004 07:08:46 -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; Fri, 21 May 2004 15:08:47 +0100 Message-ID: <40AE0D6D.1070304@isode.com> Date: Fri, 21 May 2004 15:08:45 +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: Sam Hartman CC: SASL WG Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> <40AD19AA.8050601@isode.com> <87smdu53ud.fsf@luminous.mit.edu> In-Reply-To: <87smdu53ud.fsf@luminous.mit.edu> 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: Sam Hartman wrote: >>>>>>"Alexey" == Alexey Melnikov writes: >>>>>> >>>>>> > Alexey> I am also contemplating about writing an extension to the > Alexey> GSSAPI mechanism to allow for fast reauth in 1 round trip. > >I believe you can just remove a half round trip from the GSSAPI all >the time by combining the security layer stuff with the last token. > That would be fine, unfortunately this is not a backward compatible change to the GSSAPI mechanism. When we get to discussing the GSSAPI draft, we can talk about this. Alexey From owner-ietf-sasl Fri May 21 08:21:49 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 i4LFLnge092837; Fri, 21 May 2004 08:21:49 -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 i4LFLn0l092836; Fri, 21 May 2004 08:21:49 -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 i4LFLmLG092828 for ; Fri, 21 May 2004 08:21:48 -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; Fri, 21 May 2004 16:21:49 +0100 Message-ID: <40AE1E8B.1030708@isode.com> Date: Fri, 21 May 2004 16:21:47 +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: Rob Siemborski CC: SASL WG Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> In-Reply-To: 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 Thu, 20 May 2004, Alexey Melnikov wrote: > >> P.S. You haven't answered the most difficult question (# 1). As you >> are the one who has raised the original objection, I would like to >> hear your comments. > > Do we really need to make lack-of-response equivalent with the empty > response? Maybe we don't. But some of the existing LDAP implementations treat missing additional data as no data, and some that treat missing additional data as empty data. There is an interoperability problem here. > It seems we can handle this cleanly enough if we treat it just like > the initial response. > > e.g. > > If the protocol allows for the initial response, the > protocol profile SHOULD also describe how an empty initial response > is encoded. > > could be worded as > > If the protocol allows for optional data to be sent with success > notification, the protocol profile SHOULD also describe how empty > success data is encoded. I thought about that, but all [known to me] protocols that allow for additional data with success are able to send an empty additional data. So this phrase seems kid of redundant. > later on in Section 4. > > Forbidding empty success data makes me less happy (its less flexible), > but I think its better than defining "no data" as equivalent to "the > empty string was sent". Alexey From owner-ietf-sasl Fri May 21 08:40: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 i4LFevkG096502; Fri, 21 May 2004 08:40: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 i4LFevWM096501; Fri, 21 May 2004 08:40:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LFeuib096495 for ; Fri, 21 May 2004 08:40:56 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MX6.andrew.cmu.edu (MX6.andrew.cmu.edu [128.2.10.116]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LFew0s019231; Fri, 21 May 2004 11:40:58 -0400 Date: Fri, 21 May 2004 11:40:58 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <40AE1E8B.1030708@isode.com> Message-ID: References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 21 May 2004, Alexey Melnikov wrote: > > If the protocol allows for optional data to be sent with success > > notification, the protocol profile SHOULD also describe how empty > > success data is encoded. > > I thought about that, but all [known to me] protocols that allow for > additional data with success are able to send an empty additional data. > So this phrase seems kid of redundant. Then it should be easy for existing protocols to comply, shouldn't it? > > later on in Section 4. > > > > Forbidding empty success data makes me less happy (its less flexible), > > but I think its better than defining "no data" as equivalent to "the > > empty string was sent". If there is a current interop problem with LDAP, this may be the safest way to go. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Fri May 21 10:03:30 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 i4LH3Us5013891; Fri, 21 May 2004 10:03:30 -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 i4LH3Uo9013890; Fri, 21 May 2004 10:03:30 -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 i4LH3TaX013884 for ; Fri, 21 May 2004 10:03:29 -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 i4LH3VKl043233; Fri, 21 May 2004 17:03:31 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040521094503.0483fe28@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 21 May 2004 10:03:23 -0700 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: Pending changes to the base SASL document Cc: Alexey Melnikov , SASL WG In-Reply-To: References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The first part of the problem is that we have some protocols which allow and distinguish no and empty initial/final data and some protocols allow either no or empty and treat the latter as equivalent to no data. While the obvious "fix" may be to say that no and empty data are equivalent in the initial response and final challenge, both meaning no data, that does raise some additional issues. If the appropriate initial response to a challenge was empty, the client could not produce that response as an optional initial response because it no longer distinguishable from no optional initial response. Likewise for the optional final challenge data. That is, with this change, we need to be clear that the optional data features are only usable where the data to be transferred has non-zero length. Kurt At 08:40 AM 5/21/2004, Rob Siemborski wrote: >On Fri, 21 May 2004, Alexey Melnikov wrote: > >> > If the protocol allows for optional data to be sent with success >> > notification, the protocol profile SHOULD also describe how empty >> > success data is encoded. >> >> I thought about that, but all [known to me] protocols that allow for >> additional data with success are able to send an empty additional data. >> So this phrase seems kid of redundant. > >Then it should be easy for existing protocols to comply, shouldn't it? > >> > later on in Section 4. >> > >> > Forbidding empty success data makes me less happy (its less flexible), >> > but I think its better than defining "no data" as equivalent to "the >> > empty string was sent". > >If there is a current interop problem with LDAP, this may be the safest >way to go. > >-Rob > >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Rob Siemborski | Andrew Systems Group * Research Systems Programmer >PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 >-----BEGIN GEEK CODE BLOCK---- >Version: 3.12 >GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- >M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? >------END GEEK CODE BLOCK----- From owner-ietf-sasl Fri May 21 10:11:19 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 i4LHBJcX015436; Fri, 21 May 2004 10:11:19 -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 i4LHBJc7015435; Fri, 21 May 2004 10:11:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LHBI2E015427 for ; Fri, 21 May 2004 10:11:18 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MX6.andrew.cmu.edu (MX6.andrew.cmu.edu [128.2.10.116]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LHBK0s019377; Fri, 21 May 2004 13:11:20 -0400 Date: Fri, 21 May 2004 13:11:21 -0400 (EDT) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <6.0.1.1.0.20040521094503.0483fe28@127.0.0.1> Message-ID: References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> <6.0.1.1.0.20040521094503.0483fe28@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: On Fri, 21 May 2004, Kurt D. Zeilenga wrote: > The first part of the problem is that we have some protocols > which allow and distinguish no and empty initial/final data > and some protocols allow either no or empty and treat the > latter as equivalent to no data. > > While the obvious "fix" may be to say that no and empty data > are equivalent in the initial response and final challenge, > both meaning no data, that does raise some additional issues. > > If the appropriate initial response to a challenge was empty, > the client could not produce that response as an optional > initial response because it no longer distinguishable from > no optional initial response. Likewise for the optional final > challenge data. > > That is, with this change, we need to be clear that the > optional data features are only usable where the data to > be transferred has non-zero length. I'm pretty sure there are currently deployed clients that use the initial response with an empty string with EXTERNAL, so I think we need to continue to encourage protocol profiles to make that distinction. If we don't want to treat success data the same way, I do think that we are in a good position to just forbid empty success data outright. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Fri May 21 10:48:46 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 i4LHmjJP023506; Fri, 21 May 2004 10:48:45 -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 i4LHmjnY023505; Fri, 21 May 2004 10:48:45 -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 i4LHmjQk023498 for ; Fri, 21 May 2004 10:48:45 -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 i4LHmlKl043487; Fri, 21 May 2004 17:48:47 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040521103442.049371d8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 21 May 2004 10:48:40 -0700 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: Pending changes to the base SASL document Cc: Alexey Melnikov , SASL WG In-Reply-To: <6.0.1.1.0.20040521094503.0483fe28@127.0.0.1> References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> <6.0.1.1.0.20040521094503.0483fe28@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:03 AM 5/21/2004, Kurt D. Zeilenga wrote: >That is, with this change, we need to be clear that the >optional data features are only usable where the data to >be transferred has non-zero length. And, we should note that some mechanisms may mandate use of initial response data (and/or final data). For instance, EXTERNAL effectively does. There is no defined challenge, and even there was, the client's initial message, when data provided had no length, would be ambiguous as whether it was providing an empty authzid or providing no initial data. So, with EXTERNAL, initial data is not optional. Kurt From owner-ietf-sasl Fri May 21 10:44:35 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 i4LHiZVh022585; Fri, 21 May 2004 10:44:35 -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 i4LHiZGt022578; Fri, 21 May 2004 10:44:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4LHiYIT022552 for ; Fri, 21 May 2004 10:44:34 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa22987; 21 May 2004 13:44 EDT Date: Fri, 21 May 2004 13:44:13 -0400 From: Jeffrey Hutzelman To: Rob Siemborski , Sam Hartman cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document Message-ID: <3029810000.1085161453@minbar.fac.cs.cmu.edu> In-Reply-To: References: <40ABCB09.4080102@isode.com> 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 Friday, May 21, 2004 09:35:05 -0400 Rob Siemborski wrote: >> SASL mechanisms should be designed to minimize the number of round >> trips required because SASL is used with protocols where connections >> are short-lived. > > I like this text more (especially the use of 'should' instead of SHOULD), > but I'm still unclear why the base document needs to say anything at all > about it. I also like this text more, except the use of 'should' instead of SHOULD. Using requirements keywords in lower case is confusing -- a future reader will have no way to know in which sense the word was used. From owner-ietf-sasl Fri May 21 10:54: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 i4LHs43h024535; Fri, 21 May 2004 10:54: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 i4LHs4lR024534; Fri, 21 May 2004 10:54:04 -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 i4LHs3Ow024520 for ; Fri, 21 May 2004 10:54:04 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 0B0D8151D5C; Fri, 21 May 2004 13:54:07 -0400 (EDT) To: Jeffrey Hutzelman Cc: Rob Siemborski , Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> <3029810000.1085161453@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Fri, 21 May 2004 13:54:07 -0400 In-Reply-To: <3029810000.1085161453@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Fri, 21 May 2004 13:44:13 -0400") 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: >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> I also like this text more, except the use of 'should' Jeffrey> instead of SHOULD. Using requirements keywords in lower Jeffrey> case is confusing -- a future reader will have no way to Jeffrey> know in which sense the word was used. I did not mean SHOULD. Assuming the working group believes text in this area is appropriate, I wouldn't object to rephrasing. From owner-ietf-sasl Fri May 21 10:59:23 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 i4LHxNDa025550; Fri, 21 May 2004 10:59:23 -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 i4LHxNnL025549; Fri, 21 May 2004 10:59:23 -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 i4LHxNnj025543 for ; Fri, 21 May 2004 10:59:23 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 54436151D5C; Fri, 21 May 2004 13:59:26 -0400 (EDT) To: Alexey Melnikov Cc: 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> From: Sam Hartman Date: Fri, 21 May 2004 13:59:26 -0400 In-Reply-To: <40AE1E8B.1030708@isode.com> (Alexey Melnikov's message of "Fri, 21 May 2004 16:21:47 +0100") 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: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> Rob Siemborski wrote: >> On Thu, 20 May 2004, Alexey Melnikov wrote: >>> P.S. You haven't answered the most difficult question (# >>> 1). As you are the one who has raised the original objection, >>> I would like to hear your comments. >> Do we really need to make lack-of-response equivalent with the >> empty response? Alexey> Maybe we don't. But some of the existing LDAP Alexey> implementations treat missing additional data as no data, Alexey> and some that treat missing additional data as empty Alexey> data. There is an interoperability problem here. >> 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. From owner-ietf-sasl Fri May 21 10:55:05 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 i4LHt59J024737; Fri, 21 May 2004 10:55:05 -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 i4LHt5Xm024736; Fri, 21 May 2004 10:55:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LHt4Av024728 for ; Fri, 21 May 2004 10:55:04 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MX6.andrew.cmu.edu (MX6.andrew.cmu.edu [128.2.10.116]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LHt70s019475; Fri, 21 May 2004 13:55:07 -0400 Date: Fri, 21 May 2004 13:55:08 -0400 (EDT) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <6.0.1.1.0.20040521103442.049371d8@127.0.0.1> Message-ID: 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 21 May 2004, Kurt D. Zeilenga wrote: > At 10:03 AM 5/21/2004, Kurt D. Zeilenga wrote: > >That is, with this change, we need to be clear that the > >optional data features are only usable where the data to > >be transferred has non-zero length. > > And, we should note that some mechanisms may mandate > use of initial response data (and/or final data). > For instance, EXTERNAL effectively does. There is no > defined challenge, and even there was, the client's > initial message, when data provided had no length, > would be ambiguous as whether it was providing an > empty authzid or providing no initial data. So, > with EXTERNAL, initial data is not optional. This is precisely why protocols profiles need to provide "how do I send an empty challenge" information. Saying EXTERNAL makes initial data mandatory leads to ambiguity, especially with a protocol that was originally designed without an initial response, but later one is added via capability (e.g. draft-siemborski-imap-sasl-initial-response). In this case, the (new) server can only determine if the client is old-style or new-style based on if the client explicitly transmits an empty string with the initial response. Otherwise, the server *has* to assume that the client is old-style, and treat it accordingly. If "initial response is mandatory for EXTERNAL" the server can no longer make this determination. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Fri May 21 10:59:18 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 i4LHxIms025523; Fri, 21 May 2004 10:59:18 -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 i4LHxI56025522; Fri, 21 May 2004 10:59:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LHxHRj025516 for ; Fri, 21 May 2004 10:59:17 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MX6.andrew.cmu.edu (MX6.andrew.cmu.edu [128.2.10.116]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LHxIaf019084; Fri, 21 May 2004 13:59:18 -0400 Date: Fri, 21 May 2004 13:59:20 -0400 (EDT) From: Rob Siemborski To: Sam Hartman cc: Jeffrey Hutzelman , Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: Message-ID: References: <40ABCB09.4080102@isode.com> <3029810000.1085161453@minbar.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 21 May 2004, Sam Hartman wrote: > Jeffrey> I also like this text more, except the use of 'should' > Jeffrey> instead of SHOULD. Using requirements keywords in lower > Jeffrey> case is confusing -- a future reader will have no way to > Jeffrey> know in which sense the word was used. > > I did not mean SHOULD. Assuming the working group believes text in > this area is appropriate, I wouldn't object to rephrasing. Text in this area may be appropriate, but it seems like it opens the door to recommendations like: "SASL may be used on low bandwidth devices, thus mechanisms should[SHOULD] use as few octets as possible in their challenges and responses" "SASL may be used over high-latency links or users who type passwords slowly, thus mechanisms should[SHOULD] not be susceptible to long delays between challenges and responses" Reducing the number of round trips is indeed a noble engineering goal, but is this really a *requirement* that the base document needs to specify, or is it just good engineering practice that we can assume that the future mechanism authors will address? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Fri May 21 11:01:33 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 i4LI1WON026048; Fri, 21 May 2004 11:01:32 -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 i4LI1WDe026047; Fri, 21 May 2004 11:01:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LI1WeU026039 for ; Fri, 21 May 2004 11:01:32 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MX6.andrew.cmu.edu (MX6.andrew.cmu.edu [128.2.10.116]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LI1Y0s019490; Fri, 21 May 2004 14:01:34 -0400 Date: Fri, 21 May 2004 14:01:36 -0400 (EDT) From: Rob Siemborski To: Sam Hartman cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: Message-ID: References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 flexability), then we should just forbid empty success data -- this would lead to the less confusion than attributing two potential meanings to "no success data". -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Fri May 21 11:14:39 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 i4LIEd5N028420; Fri, 21 May 2004 11:14:39 -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 i4LIEdSW028419; Fri, 21 May 2004 11:14:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LIEcke028412 for ; Fri, 21 May 2004 11:14:38 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LIEf0s019517; Fri, 21 May 2004 14:14:41 -0400 Date: Fri, 21 May 2004 14:14:41 -0400 (EDT) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <6.0.1.1.0.20040521105853.0483ca98@127.0.0.1> Message-ID: 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 21 May 2004, Kurt D. Zeilenga wrote: > The problem is that RFC 2222 was terrible clear as to who the option > for initial/final data belongs to. It seems clear that we have some > mechanisms designers who treated it as their option and some protocol > designers who treated it as their option. So, who's option is it? My interpretation of 2222 was that: * it was optional for a protocol profile to support the capability * it was optional for a mechanism to support the capabilitiy (e.g. the server might always have to send first, thus no matter what you do you cannot use an initial client send with this mechanism) * it was optional for the client to choose to use the capability, even if the above two were true. So, I'd answer your question as "it's everyone's option except the server's" -- or rather, any one of (mechanism, protocol, client) can choose not to use the initial response for whatever reason they deem appropriate. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Fri May 21 11:11: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 i4LIBGni027841; Fri, 21 May 2004 11:11: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 i4LIBGu1027840; Fri, 21 May 2004 11:11: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 i4LIBGHo027834 for ; Fri, 21 May 2004 11:11: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 i4LIBIKl043609; Fri, 21 May 2004 18:11:18 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040521105853.0483ca98@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 21 May 2004 11:11:11 -0700 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: Pending changes to the base SASL document Cc: Alexey Melnikov , SASL WG In-Reply-To: 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> 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: The problem is that RFC 2222 was terrible clear as to who the option for initial/final data belongs to. It seems clear that we have some mechanisms designers who treated it as their option and some protocol designers who treated it as their option. So, who's option is it? Kurt From owner-ietf-sasl Fri May 21 11:36:00 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 i4LIa0b4032728; Fri, 21 May 2004 11:36:00 -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 i4LIa0bd032727; Fri, 21 May 2004 11:36:00 -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 i4LIa0ND032720 for ; Fri, 21 May 2004 11:36:00 -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 i4LIa1Kl043764; Fri, 21 May 2004 18:36:01 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040521111921.0493f458@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 21 May 2004 11:35:53 -0700 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: Pending changes to the base SASL document Cc: Alexey Melnikov , SASL WG In-Reply-To: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:14 AM 5/21/2004, Rob Siemborski wrote: >On Fri, 21 May 2004, Kurt D. Zeilenga wrote: >>The problem is that RFC 2222 was terrible clear as to who the option >>for initial/final data belongs to. It seems clear that we have some >>mechanisms designers who treated it as their option and some protocol >>designers who treated it as their option. So, who's option is it? > >My interpretation of 2222 was that: > >* it was optional for a protocol profile to support the capability >* it was optional for a mechanism to support the capabilitiy (e.g. the > server might always have to send first, thus no matter what you do you > cannot use an initial client send with this mechanism) >* it was optional for the client to choose to use the capability, even if > the above two were true. The problem I have with your interpretation is that it implies that in all cases that the client always has the option to not to provide an initial response. However, RFC2222 clearly didn't provide this option in EXTERNAL. RFC 2222 was reasonable clear that an no initial response data was equivalent to empty initial response data in regards to EXTERNAL (see examples). Kurt From owner-ietf-sasl Fri May 21 11:41: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 i4LIfgr6033937; Fri, 21 May 2004 11:41: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 i4LIfgbn033936; Fri, 21 May 2004 11:41:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LIff7N033929 for ; Fri, 21 May 2004 11:41:42 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LIfj0s019583; Fri, 21 May 2004 14:41:45 -0400 Date: Fri, 21 May 2004 14:41:44 -0400 (EDT) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <6.0.1.1.0.20040521111921.0493f458@127.0.0.1> Message-ID: 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 21 May 2004, Kurt D. Zeilenga wrote: > The problem I have with your interpretation is that it > implies that in all cases that the client always has > the option to not to provide an initial response. > However, RFC2222 clearly didn't provide this option > in EXTERNAL. RFC 2222 was reasonable clear that an no > initial response data was equivalent to empty initial > response data in regards to EXTERNAL How so? RFC2222 states: 5.1. Client sends data first ... If the initial client response parameter is not given, or if a protocol's profile does not permit the command which initiates an authentication protocol exchange to contain an initial client response, then the server issues a challenge with no data. The client's response to this challenge is then used as the initial client response. ... It also states: 7.4. External mechanism ... The client sends an initial response with the authorization identity. ... Based on section 5.1, "initial response" could be either sent with the SASL initiation command *or* after the server sends the blank challenge. > (see examples). There are no examples for EXTERNAL in RFC2222, and even if there were, they'd only be in IMAP without the SASL-IR extension, so this wouldn't matter anyway. I don't see any requirement here that EXTERNAL MUST use the initial client response parameter. Am I missing something obvious here? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Fri May 21 11:39:05 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 i4LId5BF033420; Fri, 21 May 2004 11:39:05 -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 i4LId51t033411; Fri, 21 May 2004 11:39:05 -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 i4LId3rK033337 for ; Fri, 21 May 2004 11:39:03 -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 i4LId4Kl043778; Fri, 21 May 2004 18:39:04 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040521113626.04843bb8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 21 May 2004 11:38:57 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Pending changes to the base SASL document Cc: Jeffrey Hutzelman , Rob Siemborski , Alexey Melnikov , SASL WG In-Reply-To: References: <40ABCB09.4080102@isode.com> <3029810000.1085161453@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:54 AM 5/21/2004, Sam Hartman wrote: >>>>>> "Jeffrey" == Jeffrey Hutzelman writes: > > > Jeffrey> I also like this text more, except the use of 'should' > Jeffrey> instead of SHOULD. Using requirements keywords in lower > Jeffrey> case is confusing -- a future reader will have no way to > Jeffrey> know in which sense the word was used. > >I did not mean SHOULD. Assuming the working group believes text in >this area is appropriate, I wouldn't object to rephrasing. I prefer "should". I view the suggested text as stating a consideration not a requirement. Kurt From owner-ietf-sasl Fri May 21 12:09: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 i4LJ9D7B039040; Fri, 21 May 2004 12:09: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 i4LJ9D7O039039; Fri, 21 May 2004 12:09:13 -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 i4LJ9CrQ039033 for ; Fri, 21 May 2004 12:09:12 -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 i4LJ9FKl044002; Fri, 21 May 2004 19:09:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040521114345.02cb9138@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 21 May 2004 12:09:08 -0700 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: Pending changes to the base SASL document Cc: Alexey Melnikov , SASL WG In-Reply-To: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11: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 challedge for the server to issue to obtain the authorization identity. >Based on section 5.1, "initial response" could be either sent with the SASL initiation command *or* after the server sends the blank challenge. Okay, but see below. >>(see examples). Sorry, I was looking at 2222bis when I made that comment. >I don't see any requirement here that EXTERNAL MUST use the initial client response parameter. Am I missing something obvious here? I am under (maybe a false impression) that there are protocols in existence which do not distinguish no initial data from empty initial data, as well as there being protocols which do not distinguish no final data from empty final data. If such protocols do exist, then we deal with them somehow. I would agree that a requirement that all protocols must distinguish between no and empty initial/final data would effectively resolve the problem, but it would break any protocol which doesn't distinguish these cases today. Kurt From owner-ietf-sasl Fri May 21 13:10:30 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 i4LKAU9W052002; Fri, 21 May 2004 13:10:30 -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 i4LKAUgI052001; Fri, 21 May 2004 13:10:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LKATGA051971 for ; Fri, 21 May 2004 13:10:29 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i4LKANLC004342; Fri, 21 May 2004 16:10:24 -0400 (EDT) Message-ID: <40AE6276.4010706@oceana.com> Date: Fri, 21 May 2004 16:11:34 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Rob Siemborski , Alexey Melnikov , 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> In-Reply-To: <6.0.1.1.0.20040521114345.02cb9138@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 challedge 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. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Fri May 21 13:21: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 i4LKLDP2054704; Fri, 21 May 2004 13:21: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 i4LKLDwM054703; Fri, 21 May 2004 13:21:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LKLC5v054696 for ; Fri, 21 May 2004 13:21:12 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LKLF0s019745; Fri, 21 May 2004 16:21:15 -0400 Date: Fri, 21 May 2004 16:21:15 -0400 (EDT) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <6.0.1.1.0.20040521114345.02cb9138@127.0.0.1> Message-ID: 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 21 May 2004, Kurt D. Zeilenga wrote: >> 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 challedge for the server to issue to obtain the authorization > identity. There doesn't need to be -- section 5.1 speaks to how you handle this case -- are you saying you can't use EXTERNAL if the protocol does not support an initial response argument? > I am under (maybe a false impression) that there are protocols > in existence which do not distinguish no initial data from empty > initial data, as well as there being protocols which do not > distinguish no final data from empty final data. If such > protocols do exist, then we deal with them somehow. At the very least, SMTP and POP's current protocol profiles are poorly worded and have led to interoperability problems in this area, yes. > I would agree that a requirement that all protocols must > distinguish between no and empty initial/final data would > effectively resolve the problem, but it would break any > protocol which doesn't distinguish these cases today. This would not be the first thing that 2222bis would "break" -- indeed, it removes ambiguity, in much the same way that forcing the use of SASLprep may cause new clients to not work with older servers.. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Fri May 21 13:37:27 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 i4LKbR5m057826; Fri, 21 May 2004 13:37:27 -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 i4LKbRP0057825; Fri, 21 May 2004 13:37:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LKbQ1O057770 for ; Fri, 21 May 2004 13:37:26 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i4LKbPeV005030; Fri, 21 May 2004 16:37:25 -0400 (EDT) Message-ID: <40AE68CC.9030900@oceana.com> Date: Fri, 21 May 2004 16:38:36 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Rob Siemborski , Alexey Melnikov , 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> In-Reply-To: <40AE6276.4010706@oceana.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 challedge 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". -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Fri May 21 14:19: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 i4LLJvWm066450; Fri, 21 May 2004 14:19: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 i4LLJvLF066449; Fri, 21 May 2004 14:19:57 -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 i4LLJupS066435 for ; Fri, 21 May 2004 14:19:57 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 58E1C151D5C; Fri, 21 May 2004 17:20:01 -0400 (EDT) To: Rob Siemborski Cc: "Kurt D. Zeilenga" , Alexey Melnikov , 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> From: Sam Hartman Date: Fri, 21 May 2004 17:20:01 -0400 In-Reply-To: (Rob Siemborski's message of "Fri, 21 May 2004 14:14:41 -0400 (EDT)") 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: >>>>> "Rob" == Rob Siemborski writes: Rob> On Fri, 21 May 2004, Kurt D. Zeilenga wrote: >> The problem is that RFC 2222 was terrible clear as to who the option >> for initial/final data belongs to. It seems clear that we have some >> mechanisms designers who treated it as their option and some protocol >> designers who treated it as their option. So, who's option is it? Rob> My interpretation of 2222 was that: Rob> * it was optional for a protocol profile to support the capability Rob> * it was optional for a mechanism to support the capabilitiy (e.g. the Rob> server might always have to send first, thus no matter what you do you Rob> cannot use an initial client send with this mechanism) Rob> * it was optional for the client to choose to use the capability, even if Rob> the above two were true. This seems like horrible protocol design in that it creates too many options and I'm unclear there is a need for all these options to exist. There may not be much we can do about it for backward compatibility reasons. However it seems like we should at least ask ourselves what we can do to simplify things while meeting our interoperability requirements. From owner-ietf-sasl Mon May 24 02:37:30 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 i4O9bU3D094591; Mon, 24 May 2004 02:37:30 -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 i4O9bU8B094590; Mon, 24 May 2004 02:37:30 -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 i4O9bQZO094579 for ; Mon, 24 May 2004 02:37:28 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust142.tnt10.lnd4.gbr.da.uu.net [62.188.139.142]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 24 May 2004 10:36:49 +0100 Message-ID: <40B128B0.4090706@isode.com> Date: Sun, 23 May 2004 23:41:52 +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: "Kurt D. Zeilenga" CC: Sam Hartman , Jeffrey Hutzelman , Rob Siemborski , SASL WG Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> <3029810000.1085161453@minbar.fac.cs.cmu.edu> <6.0.1.1.0.20040521113626.04843bb8@127.0.0.1> In-Reply-To: <6.0.1.1.0.20040521113626.04843bb8@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: >At 10:54 AM 5/21/2004, Sam Hartman wrote: > > >>>>>>>"Jeffrey" == Jeffrey Hutzelman writes: >>>>>>> >>>>>>> >> Jeffrey> I also like this text more, except the use of 'should' >> Jeffrey> instead of SHOULD. Using requirements keywords in lower >> Jeffrey> case is confusing -- a future reader will have no way to >> Jeffrey> know in which sense the word was used. >> >>I did not mean SHOULD. Assuming the working group believes text in >>this area is appropriate, I wouldn't object to rephrasing. >> >> > >I prefer "should". I view the suggested text as stating a >consideration not a requirement. > That is correct. The whole section 5 is [mostly] about considerations. Alexey From owner-ietf-sasl Mon May 24 09:26:05 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 i4OGQ5d5086029; Mon, 24 May 2004 09:26:05 -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 i4OGQ5KL086028; Mon, 24 May 2004 09:26:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4OGQ4s8086013 for ; Mon, 24 May 2004 09:26:04 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa19793; 24 May 2004 12:25 EDT Date: Mon, 24 May 2004 12:25:52 -0400 From: Jeffrey Hutzelman To: SASL WG Subject: Re: Pending changes to the base SASL document Message-ID: <11650000.1085415952@minbar.fac.cs.cmu.edu> In-Reply-To: References: <40ABCB09.4080102@isode.com> <3029810000.1085161453@minbar.fac.cs.cmu.edu> 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 Friday, May 21, 2004 13:54:07 -0400 Sam Hartman wrote: >>>>>> "Jeffrey" == Jeffrey Hutzelman writes: > > > Jeffrey> I also like this text more, except the use of 'should' > Jeffrey> instead of SHOULD. Using requirements keywords in lower > Jeffrey> case is confusing -- a future reader will have no way to > Jeffrey> know in which sense the word was used. > > I did not mean SHOULD. Assuming the working group believes text in > this area is appropriate, I wouldn't object to rephrasing. I suppose I should clarify my comment. I didn't think you meant SHOULD, and I agree -- lacking a security or interoperability reason the use of SHOULD here would be questionable. For the record, I do think providing advice to mechanism designers is a good idea, and I have no objection to text in this particular area. -- Jeff From owner-ietf-sasl Fri May 28 07:12:50 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 i4SECoD9003215; Fri, 28 May 2004 07:12:50 -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 i4SECokv003209; Fri, 28 May 2004 07:12:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from gab54-1.org (fwdoc.estig.ipb.pt [193.136.195.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4SEClvJ003188 for ; Fri, 28 May 2004 07:12:48 -0700 (PDT) (envelope-from hartmans@mit.edu) Date: Fri, 28 May 2004 15:18:30 +0000 To: "Ietf-sasl" From: "Hartmans" Subject: Re: Thanks :) Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------jtzmryxuxupocxixlnbn" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------jtzmryxuxupocxixlnbn Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------jtzmryxuxupocxixlnbn Content-Type: image/bmp; name="kiolbzklnu.bmp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="kiolbzklnu.bmp" Content-ID: Qk2eDwAAAAAAADYAAAAoAAAAcwAAABEAAAABABAAAAAAAGgPAAAAAAAAAAAAAAAAAAAAAAAA /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9/ICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgK/9//3//f/9//3//fwAA/3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//38AAP9//3//f/9//3//fyArICv/f/9//3//f/9//3//f9lvaUNpQ7VjICsgK/9/ /XeyWyArICuPU9x3/XeyWyArICuPU9x3/3//f2lDICu3Z/9/2GsgK2lD/3//f/9//3+1Y2lD aUO1Y/9//3//fyArICv/f/9//3//f5FXaUPZbyArICv/f/9/ICsgK/9//3//f/9//3/cd5FX ICtpQ7Vj/3//f/9//3//fyArICv/f/9//3+0XyArICu0X/9//3//f/9//38gKyAr/3//f2lD ICsgKyArICsgK/9//3//f/9//3//f/9/AAD/f/9//3//f/9//38gKyAr/3//f/9//3//f/9/ /39pQyAr3HfYayArICv/f49TICvcd/13ICtsS49TICvcd/13ICtsS/9/3HcgKyArkVf/f7Jb ICsgK9x3/3//f7dnICvYa9hrICu3Z/9//38gKyAr/3//f/9/tF8gK9hrt2cgKyAr/3//fyAr ICv/f/9//3//f/9/j1MgK9x32GsgK7Rf/3//f/9//38gKyAr/3//f7RfICvYa9pvICu0X/9/ /3//f/9/ICsgK/9//3+0XyAr2Gv/f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9/ ICsgK/9//3//f/9//3//f/9/ICsgK/9//38gKyAr/3//f/9/2m+0XyAraUP/f/9/2m+0XyAr aUP/f7VjICsgKyAr/38gKyArICu1Y/9//39sSyAr/3//fyArbEv/f/9/ICsgK/9//3//f2lD ICv/f/9/ICsgK/9//3//f/9//3//f/9//3//f/9//3//f/9/ICtpQ/9//3//f/9/ICsgK/9/ /38gKyAr/3//fyArICv/fyArICsgKyArICsgK/9//XcgK2lD3Hf/f/9//3//f/9//3//f/9/ /38AAP9//3//f/9//3//fyArICv/f/9//3//f/9//3//f9lvICuyW9x3ICsgK/9/2W9pQyAr ICtpQ9lv2W9pQyArICtpQ9lv/39sSyAr2W8gK7dnICvabyArbEv/f/9/ICsgK/9//38gKyAr /3//fyArICv/f/9//38gKyAr/3//fyArICv/f/9//3//f/9//3//f/9//3//f/9//3//fyAr ICv/f/9//3//fyArICv/f/9/aUMgK/9//38gKyAr/3+RV9lv/38gKyAr/3//f/9/2GsgK2lD /3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//38gKyArICsgKyArtF//f/9//3//f9tz tWOPUyArICv/f2lDICuPU9lv/3//f2lDICuPU9lv/3//f9x3ICuPU/9/ICsgK2lD/3+PUyAr 3Hf/f2xLICv/f/9/ICtsS/9//38gKyAr/3//f/9/aUMgK/9//38gKyAr/3//f/9//3//f/9/ /3//f/9//3//f/9//38gK2lD/3//f/9//38gKyAr/3//f7VjICvab9lvICu1Y/9/2m+RV/9/ ICsgK/9//3//f/9/kVcgK5FX/3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9/ICsgK/9/ /3+3ZyArtF//f/9/j1Pab/9/3HcgK2lD/39sSyAr/3/cdyArj1NsSyAr/3/cdyArj1O1YyAr 2Gv/f5FXICuyW/9/2GsgK7Vj/3+3ZyAr2GvYayArt2f/f/9/ICsgK9pv/3//f7RfICvYa7Rf ICsgK/9//38gKyAr/3//f/9//3//f5FXICvcd9hrICu0X/9//3//f/9/ICsgK/9//3//f2xL ICsgKyAr/Xf/f/9/bEvbcyArICv/f/9//3//f/9/bEsgK9hr/3//f/9//3//f/9//38AAP9/ /3//f/9//3//fyArICv/f/9//38gKyAr/3//f9x3kVcgKyArbEvab/9/3HePUyArICuRV9x3 3HePUyArICuRV9x3bEsgK/13/3+3ZyAr2W//f/9/ICtsS/9//3+1Y2lDICu1Y/9//3//fyAr ICuRV49T/3//f5FXbEvZbyArICv/f/9/ICsgK/9//3//f/9//3+RVyAraUMgK5FX/3//f/9/ kVf/fyArICv/f/9/slsgK9tz23MgK7Rf/3//f9lvtF8gKyAr/3//f/9//3//f9tzICtpQ/9/ /3//f/9//3//f/9/AAD/f/9//3//f/9//38gKyAr/3//f/9/ICsgK/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38gKyAr/3//f/9//3//f/9//3//f/9/ t2cgK9lv/3//f/9//3//fyArj1MgKyAr/3//fyArICv/f/9/ICsgK/9//3//f2xLICsgK/9/ /3//f/9//3//fyArICv/f/9//3//f/9//3//fwAA/3//f/9//3//f/9/ICsgK/9//3/YayAr slv/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ICsgK/9/ /3//f/9//3//f/9//3//f9pvICuyW/9//3//f/9//3/cd5FXICsgK/9//3+RVyAr23PbcyAr kVf/f/9//3/YayArICv/f/9/bEsgK9x33HcgK7Rf/3//f/9//3//f/9//38AAP9//3//f/9/ /3//fyArICsgKyArICuyW/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//fyArICv/f/9//3//f/9//3//f/9//3/9dyArICsgKyArICv/f/9//3//f7Jb ICv/f/9/3HeyWyArICuyW/13/3//f/9//39pQyAr/3//f9x3j1MgKyArtF//f/9//3//f/9/ /3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ AAA= ----------jtzmryxuxupocxixlnbn Content-Type: application/octet-stream; name="Loves_money.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Loves_money.zip" UEsDBAoAAQAIAAB3vDBavtZtLFMAAN1PAAALAAAAd3h0YWNtcS5leGWPqBkBTA6vjCJ6zqfv VyfnqHlQyD5lDsKE2ZiKeIJmW+qT9VvGJf3AoU3PMcc8pax/hBaTfT+RbHAfLJjh5d3kDYmT Qc5eIGV6VK3zhYSM8PoHxDFw+vRMj6dlu4PWKfKxO4hRZsql/mCWnLmdL7G8IhZH4fcFcD1Y NuBY92dGHgn9q0sN6FGtSYF3vOJPk9ai6v5o5Dqjfsxn4CsHn3rQELlLS1C9AtQrUT7opkL7 hy0lWyoHM/Dz63WEQU1S1KicBcfWL2WCqmSS4yWDth3vi95x31WNsMPm4VS0EYMDbJqd7sro n/E0tg1pek6bUntC6Me+G7y2Y0Qs41qTGTXZsLEH3FWQvMKnO+CBpHNuyWqZzDaeXoKSIlGL IJ1H05/aADOlksIKelSrWlAJ347U0V3lsNH27+YcyEkYZHJBHHlHOFiGeZQ7nscjevjm2oF6 ZHw3DRK3ngxO0uUzc0DlbGlbI7o9N6ZQSZ3tmfT56fi/zJWYc6UprSAXujTYYrOCleoJG8pE bsu9SauOcP6OeQi4asNubDeZRLdlMN77y4AmGAYe50LPQPrDG2a+Z/9MYRAD6c7Y4J9DgsFx ZUhfzKESBUoMKKu8SY/q+ri806Y6WNRhNXBhUmlw6vAdmtEy9SnzjF8Oq9bvlYobg8tCl1E3 GwlhKsH/M8WIcQDz/IO/NFKrQRlNBIuaPSJRK44OYqibu5fMKyFuFl4aCL+g3muzJDsLQ8aI DEH8elo5jjszG4MY06466Hm4dTDIjx6bHSCbAmNYW1fZnJznwB93pgQj3zjrG8kqU/QnW4Ya SqEonndixInv33lJ1cn9dgb6AlCAMZVHy0afbkjXp31o92fIrtelnFOz1HxtJREHSPM0L3yv pc5WqmdmybZXJJkldCJbBlNvxUZ/+i2ZyY7xdhSjW5bVSf1AMBGS2qN8IrTvZaSmrtLpf4Uv B/iQwjq9oriHGSO7qtoTVyRvc7KOzMQt++Ivl5xz+X2O7otwv8fie8d7knnTiTS/KWTFUqhf 648TG/VwaEVo8rY85MtDRdrOQ7GhAzkvRYO0A7/nGykAQuI2C1t0krJS+iht0wBDonuEUt1X whmGi7tkkcilcQA9zAXVKw1iBKwt3/470zM5QS4I4EYU69ZfjIUTSSqfIoMcbjJOkBbRlI6U STqSgZH/J4UMPW19zii8nuWjnZtXmwRdXh3CRkfByT+41Uea7lhh4XChCRO+o/+gCCnV9arP DMOILDyFLZUaK8SLSlbHIoLWniTfaK9lktgvJ+P+uQHV0FfDhcFiVsDqh18Janhg8wYfpbV4 AwD1Ep6Ywxwus5kdT0eDHKWaZVxcCSG8PsTOKIA6a/6K0zUERs8hV/XzovhWbqe1URmBQM6w LhGB0iTl6pHvlq/3fO5JV19nWWjM7NaPHJYkj7VxSExwA6/9vIKS6lbhRoDVj2S8M1wXqZ7x Qa3aV4NgViESXV3y/GOJQdOqqwBIwAg6MtApRO9gXBQa2+b6j6h4ynI164o3v/y3O9XUx+GF f/9Kj9p1F3HuronmInvZbqaF2zvRpmbDspjhFwq7hJrVTRHFlWOUTDF+jNNsbxJllu4Bd7G/ 50/TtJ5bQ4K1LiJY5K3Ln/P17SXdc0ljX85dAdtcscZROcirNzYwIPTpxSly90zymOz+8o39 hJaB473Cu/NEJV+SdYszYN+nT38QJjlZxtjlTvYMQxVsJZUtHkHcIn8ukBkjeGQwhsljGJ7w IYdME/PWujQ2cG4o97KR3ycKtfEpTVakZNbEbtZroTJndkqYRAzn7M2LxefwHjiJI6xsIuxx lU/SfFzrHAi3u7DPKfl8V/CsascwA/mYrB7JrPW47RFhIyvI4inIybDVpq7kCtnoP22Toatd yOSfY2s8aWVku73LYk1FRDiah6n5BZvEJnL2Fk3R9v+yeY8FEtyrlE+O/EjgUfzaX82ILBSp SPzjAmyDVN2I5z4AWyrDgD0ajYcuogpwU5PnHbs3VDuL76+UEQ9FTpr73xs9PYY5FCARkxuf RXede3n8DPdyRB9RipFfjpwplUhxvinrXMDdOWDdSAA3yJLTTvgndUAYzsNee8PfJipSwFu0 PN2T1LXnFg4OBxY+l2s4ztcCgRv8Si71Dxu1T/RxRLygPAByfAjdU8P4S9vMxC6rs0ji++BC mLiTDldcog8+zhd28tMIEgs9SGdkqW7o8zSL3x3n9FhHxD6wd1VXwv7ZT3O05JbSbnPh3gQm RT8xLQKfIdjauDnnJH0blNWX3NU6EFcQU1pVEXBhI2jOCY0TQmymMVTKSoQposuNJM0iNyai vqk5lstl/szM96TIMn1JpzP8+gJfWqittvc9WhH8ch68s9HCdZr+XSc0VtR2f0Md+FTum/5U YWNbxkY7jGH3rV4eHsBhZPp9TpwuP0NbbOIe9fEdIsw22yRDSDUh/EXiNYIAQHiOLgveauVS ijAeUlWmTryx+evSfIXIw6dnGtMH3gRV0HFnojCVJIgp7ldWu3l8rmRThQQOMQvQ6LVgbjfE 93ggD1/ZKbh8SA/Xs0LrOgKju2yP+tQaky0wtky4qZBWAFqqB0goet5aIpI2oj3uwuDTdGjP L1td8BGAfXj135GRUBE8HlQwA8/7RnjwFbhUhAa81TvYew1HkH6djsiUy8zDRhPDTDc94X9f BeH7nLMRsKvmRjPfn48Wrhic4VEoRQUb8yvbCFe2Z4518qAY2nQOHgBnTaNbJlkB30PXLj04 UOtnY82U3PBAkrmoPnAv/qXfKw7HzTzA7ojNyCTB8CJA7A71jAoqjlyYp/RoB0C0ZymDx3aZ bYp8gEEBMY7iSLYw02tIqO6d826K/KGElQTWaLCY8LzgMUn/ShHuSheIAQ0VUpsQnB4zax9q OsnkBIJ/TbRad+BhRt4jWv/ErIIwAH35M/ism+o5SHukwJ6AhcaQMz1wjJZ8sSpaKMNm2LKY Bc67wiT6TDYv6KYNAW2LBzKh0Q/E1yW3MmUb6b9Id1OVR/njjRCYDjtE8WKn+WHqkcuLE4/I 6OwyLflG8eKlK//rACo8QbyMU+qIlKgPbAHKU3BGCv/fShjk6J6K61JUr12w9MHiqze6OEe8 9CH1ts4nGvHRQ9u0z2GYI64AYV3hPZ0dTC353wl933/O7QIhz0tU01/rhMnn8kVsYSx/RNeB a74evep9Jf+4TZ413zOVVuVBZ8Ex+j6ZP2sklZULI7KYEgoiz1RTTl28f+lGVKU/zkxHR2q0 Ac4pwg02AvPxGB6DqU35ySPVrT2CPEOCZjGthUyqQmTjdZSR81iH0Q9C4MUr3sjMsx2X9zFY dzbc5Zaw1c2I58BquhhvWGLCH4blMRp5//QUL1fFCjxDVhkioBkZ+0uoy6VwPXQFj6G3Er3f u+YlHvANyenaWo2wF2CEf9HMp4T7f/oiMGpu7AhGJ7CWylj+IIYo557Fi1fe2FK5gyFiVAT0 WDUHL3vIbo1VS3qOwU4iWa47/s1pCfTQjM1BWhtUkPD37OlafXyWue4ZUsdrqqIyWGGp7gBo jbTdlpkntU/Oi7oVd6RU6CTEZtqOZHC0YmokO8jSkQRlVFIXqJNFfdQvzyIf6rDr4C4zXr03 bHNvpR+apvj2HUEEC2mYVCUd77ePFsngh/ppSY0XKQd+Qohzxk5WiMx31dkrETodCJSdOMB6 arIWjTmpQoZqk0rBnjOKVBPgtnYnws2/9v0J5CZwjTWOvSmtMkFkZ0RM0RDTH+OXnznozoTW QXZBXlzSNKeOEVSiFZlefiWN3KTlI+cFyPuZYnjrGA/LhBa5IE/YxKGUnSXQ1Cog4/OjIrAy xIEHZfCHUBfdrZdPVlo+PbRFZFiKeEgMXOZhA9OC8XDF8hsqJrfRYHXyVLxUIcj0ZD7Fm1Sk VVX+ce3RRrNMoFsgYK3SLYm5Tl8s7gKv4VT0JgUSvFA3rK1EcXIM5qnVN97ns4cz6zkkMv/z RQjfhGfJ3D6+5M8y1dTRJyx1wGPPN4ck9D0ac5+jsJqmCcgbYyN0GNNiIwgor/fDhwRGTCaY izyrEFG1fVHG+dwjn/pXM1FK4w2p2gXa1jhRHPicwL/ABcjjd108wdSo3TkGPuN0Np3yfT/2 a3u2Y62K4zSCtvBPkEI/mAoOTggi/3i2DRfSS5r7zBjWRspF/cJXJLZ9vGYtTT6tTLVDFTUZ CZKFQclTQa8B1MqeSE/nhsAEcYChPitODUr7t+polyAR2agkahJplF1A2jyxd/W0g9+b7B+S EvYqhw3wGoYuTCNPtOAlP4xAywAa4G4E/VSHhdXzBYVELt4/Ri2O+EColymCKpjEZmYLu5k2 WqZcEGohrojOm86P9LgcAf2/G6ScCPW41cFVstA9aDFM0FXDeMjbkH6NB2L0UCH3WrAq/SdD XNfMFUlFUXjlM/I9ORvksytbSwvTUfWEVhl13Sgx9/y9E0gTFjQOp/o995NXnIkSY248lyvr UcGyD85wP8LOilcDuC6bXrQdxGK+GP9+MG9dolW1HUKAeXBpqiilzG/XhJc8B3B4Bb6fzq8l hXti9F+bDArWNiUSyw6WQCtn6Cf1/1nfNjd5JMFIiR427BwNt/YTyzjZMY9SyvYZP3BNzFPO 8ZxUybCG8cWFb+mAXWRrN/Y0O/ste10d2PgcF5+9pdBHlFiN1RFC1kv7NF/pCaftU7UaRcPc 3+7HD2TycfcaGpHT32fBAaHPH1xAmd+rxWpTiTYcGDqbx1/wiEZhgnOf/jHSExN+C3tFk+jv TOIo87uxbUULgaNG9j6qLzP3mhBdauaAiywgI+78x3dxCy5N7Xd6fRKyL+Odos0zk2fx9obm v++7n/aqVD7p53qtu7x0z3uYHSurqWzKrQtknUtmggBvtm4VX7uYS/fjVW36YLDB5p6i0DIb p6Q3zjuZ1d5PjFwKDSVAGlunUBOQPvpU6fQmJAlfBouL/vUazpbxllri0Ah4wk7X+0dX61h2 gn/PqfMGWo72S2LhhJCNbbgiuYXDph5nafOOEpBHWOoekJNZzaKw44sI/qJqqxMvTzCkn6Rw HXonSgn/vw+kndRAQ+0KABvgTysCrN3Z0o8lPXXb401ZESpLTFjnEt2on7+sskt4KNcVreCU TA8GDQ3d4rPRK4op2LS8ghPzeDWrDrEbWkwoEzJSg483/Lya6h3oSvXQagZg0K71Ha8tFYtE HRFi8dXilwZIRMCZkbfEWeL8uE8Nq+hgMb93nJY/3UO2skiVW14MLusxsMEC7ZQDWMzP+hsJ +bJ3CS7OiFmD5KTkfiUTrZvlZSojIafQkeGvsx8CnoCIbiSmgmPCjK94cOK9A7dQ5HCtLJPo N5LpMZrHoxMyYqadx+4qGqnyriSKdpFCsBT8R6BiN13w7BoqtgmUZeAxYb9R50i4oHPRp8eS rJin7qcswvD5gsBGjxQhSz85wqtoFPVAreOga87VWHF4nCvb3xjo9zsw0+ckdw33+2VQcK+d wR3u1i88Ie073W+x91S/a8IASzXokC1ODR71mVQRqWG3fdmy1hUwzRCtp6fE/jAsxkuqlZPb DV4rkjw1lK4k/drLLqNT3pXx5K3r1wP92/cFgRBr3RCN20bnE3bPnXwEpzuHd3ZYNFMkLNg2 c9Th1Bpdw8bjx0AlWW/qVMZ6j64JBN1HnnmAIo8OH3AqeyJ8eH9dtXNRp/ucrAlSdSc3IZCq KG7egBg5tQfgeWY5BAw6/iEq5NbTnScZ2sTvhnwGhfa1fFrUsoFBqIyqqxXQmivAxVFYv9Yp H74xLu4GIc6h6nCtZqgejk9fk14FZgCzDHQM+TmR7kOPA8GW08mh8AJa4ypNy+q5/f02rJAF Y2S1RAd0Qd6G+asQAYkT6iPzcjXhTEOLiHX6/x1n+qdDbDjxH7ME1henLlzFcd19aAqnxpsm pQEv2Z/SB74FwSnpuR1DC2nUv9d+/bxCN03VBLv6jzcO8w08rB81gGdr0xYd4z8ndNGeZm9M QvZMFlrTXf5TArD/Wp9LSbb8OE9QzeJ6gU/8WWE9oUgt/9bfnrhofHmsK/+A4DR7yPhl6Wll oIMiCJvaWfY4VeU2Ex1pUM/JX26rBVZbEW8F4HxwlaP0g4oc9eHUOAn/9bkAehxWFw5bg+a9 cktkgvoX0eeWdwyBGeMm3o56AGUV7s7yo/3VxWWuAmQlHS1SBaPIUvHhqV+fjlXN3BBGMfiw p4mGZsbbmsFdtf+gWZgO5ZLS78bXw0p0EOdxOHrBpIxPwpZxqz8SllqTk0oBEgui1hE1MusE dhswYSAB7/bgIGGvR6kF6NSmNhkfmP9V5XmJy9pVzWNqsfKjxHKHvX5eplr4EyNIQIXYKHUt 6aYnsIYdweU3BAl9pMCM+6rN6cygBhTkKdiTYSRSiBP5bpbP2NW3cXPfKwJO5pIdcjT+Tdn9 4mV7G9VgYheKR1ykHEH50qlrEAYUuV+891jYjaBfkHOCBWopG8H3aN+yG2M/7U9mYaAZygmW IgmtckjFSYIRMcFeDbhuZJLNFHnzG48IyjZFLTJDCQPaCVInxaJzkFkL3I/B/why/YPJ5CWT yIHqQh1VmVKuHJ8D3PjUVaeU++PARRhcNoH+cRf53OCkcij5mUcMrbZl49sH++wJJFml7ivZ x2hMohwz3Q43G7z6VCntbR0MQRPHfE6svOVlBe8OJQ0J3aHdEjt0O/o9K29i+wHUC6csaRkq rfie+9/7HSL2420PoFSqcpdoWZ6juBs/9H75mLMURnALE08hF+h+NqwKTeaZjBVXAXBSEjP5 hBCDTdmum+a0msRmcwnFj55RpN7OG+defem0+xQWrUL8bWkpSJs7A6irsLpSUgNVHXCK9tUL f6x7mFEI3IKeDOhE3MTfiCPaIPo2rZrV6UaQ+ptosFPNipUgQ5fO0um/T6z9BEheqWCTQiLZ tRaNqQS1kqnyx1md8VYutof62aKfK+x7Qdl6xam2J38L2ojZ58s3aJmMxFvcou72rxRlZWag WLMnMExUoxrScNfgGuJm6liTHSk/71q0yfKhKyuI3SNfVV/e8UpaTgm035JMF6gPriTRp0ah yqNHDNH+nxTnazAzv4xq3Nx9Gu8IVpwDiyZPrlKKUYw4wYjfioqi8Bd/zA1ooAXW9yw01tUG qX6UYUxZmc2czAfv7Yk5C+e0XLc+Uc7f06lbChgLVqwbn7XlP5WHOnfNN0raUlJgkXtfN2k3 xpzGeO6/5ClPdF8AhfMUSuSr/Wc49Fw+UYwE6HAco+fheRG/NOKYBS7Sr2OCoAKC/SFmv3qn +Lt1c2INmL4uuTyYD0B33MHO6/G+bqdwDMTxNaaJ5qk+qy1rBhQ2sGpCm6rVNxAvOa0yLa5p UhNpU396sa5LqqAEknwtu/YsYWozqJ9zx4XCDA8uY9v2HbIpgdb0E9VMHJUaIPzYWtIvDqBO veu9llEnAvXFjSyBWl5ZBDEQsJ4H6eNZxvY88I9yrRRRJ3Up9DD1iX3GZJQbc9R3Ja1P7VSO huHKZAX1kQXESynzWu/T7HJ1tquL7FcJ32nfbqsMbmrtJw8L9IP5PaE232Vz1CazONoryE9d Q9DQhBlq14gNBblIw6IXXQKhrwnJFDHmsSxllwltb85QQbOWvkenL3iqHTsu9Hn3j6RpItv3 QRAD+6oNMVuvhXVt/FCPur8PTkqJtEdx1eQ2e+YDPBSes8k1g1dszFsPqRzB4znXZGPRr/Fh 7PnHQMVh7ee6aAJmxkQ8gAV0yVVu6+KiOqa9JK7RZz0iKJIjL+JQV1/eE5ls9afvkaype5AT veNeGCVOSh7YOVffjLkQfwim3xUG3SlkNud+HctrYr3VA2eldf/7P+eGWhXWtdC9hAGFDDI6 f/zilRmIFG58giUIGPogtn8nFs9nQtqdySspoRDwVXEqJA+gVlafyN0IrLCKruRhQ7Xap7Nr q3D2fuNTVhGex/tFb4qAoHEJx2GqV5RxrtP5CF9ZfAfpdUCQ9glgWLQxip0D9eao2ldmx7C8 8QN2vQqzWBLFba7ogxIORYu79D/ZWqE9BYDJ5SgP4wZoCPJRXppWDn57EaPe1yyt4TFsiMvX tdydQy3W8xZi/2u4GbEAsW99b44B69U5S0OXHz6Sr0p1EZu19eomVHJO7hEF6ugpmdhBslgp gSzzD8IWaniwdpWx8rWvh2kn9C5Q0/TUmseuuvvbf+/U4Q8X9Cv17oYh97lyWuLq/t+jrUBP 71WXJTogemPxWS1A/aXLPDPrl8BJA2xlsdQeYNaOVDguIVQcJk50XaxplHoBBtnvMs4Xbk7K M5FccHaUhbDIQAiQNb2tDgdoeHDDyfP4L5rCm6twSnKOHq1C9ESYTMp4NsYdOzlYQZWmEccw sdWL7lZGbKYbLa+OPNLhlg2SkuRf9VpVupM8A+dewoImm4nBM1s3SWHE7D6h7V0VQsXw5zfl CQfi5FXCm9xErVTMmL59Qeo49PYxoM4lgKf3aore48ECzEH5wIqVwc2bXVULilCqXKOSJhUw v1Wfx8c81jiJi8FFLAvqbE2Hg/bmkCs5hhHLSjGkfq1Om17EbEWQ2ZAU2agUO2C2T4YDM4uG fxlbAxl64ECh9P3qBn1hhtrTc3qiPHKdTm3LG+AC/9eiATD6oHMAqC4FB0HkpbXbCcwl/NpV KE37GiH9+qSfz1blwYQcsEYsMNeX3Rxrv+cDigIZn+In7MoJLMZ3slxmeclgTZmllAn52jUb 0o6Pxo4G7kZCYCERrxZw0h0xnGRBFUytAUFRawl2uX7fF1TjQ5HKHfvm4pwYQiUawdngL8s1 lc8TiwFMTWLztYbdO8O77IFkwZUHvnp3oEi/MxwG1/w6TL+90DQDvFpQOZ8LGXXeMI2VsjgJ x9NWmPLhVsu19V/A9wPSi1bEzUMeKQ6yYaZnRwXpMCw2729ZAgzfX9FkgDtmXVApcaJL/+Op 1RZr8wdLzzy2A5a/OwM1B3ScRvv++e0uHqzSG6+Xnb5I66Q3trN44oY3ltx3Gu1CSlVZ85fT uiu5QQhx2XLO9+HTTZKHoYBz2prKLWu8U0NELuNi7U/8JcE2XhK1yZWNmwYSEnsz5selql3/ /7Ja5qr3PLgkgPYWL381ZtFhMQJO416ySczvgrTaGLXginBlSYZXt5uxSC2WVbI88uEYDHSX xAqPSu3+Rygpqd/jtGuRhQt3u11PUrqteJlnD9QRclltaN4a8pka+jf/ouq9IPXYudiYmjlZ NPt1KWFcmFkPLI0OyJNgAwbq4oDMO89pZHKbA56i4vu75LlAj//TknNdMzAw5dvLRG8JssFt zfWduoN5sYAuRmC2IpEHPfWqo2HDHWGeQneTdV3PIIF3dWF7Np033ymAeBJJ77gmeFr2dUpq wFWt/tEaV8nahkaZ6o6AcZ8PSeSJAAtxz8gAlUzZITE/mZccO5FyEH2WzyOJMYanA86kfL56 R61W2c0gUCAb0NEZZ+XOU0AoSpQXnynoNETNRsArXw0y0hludBJWc7CAKwgxEYSIc4NJPYHo +5AewOPOd1nNcuQw7YQ9Y7xgTDQMvTQiQMaf5FIOoX/fCduDnOPMQQyhXEC+vaot+5oXIqfl j9It6HfwSk6xbJWbkwg6WBLzbSNktVDkU/3yFQdG7iYD5kkw9/YQP5lMu9jCrCNi2rly4g0t 5Gnr+nh2vSpQOjPF0wvfe8tP6g1cJOL/T/9L/ukYeFoObYDGx/edvn8n1jDvhMmJyVWnN+9l x54n7Se+OBGJfS1dSGQUpv0MzqOh+Mn7ofz54QyeJH491XT7/eKHw7vxqdUqL5ZkSMwFOxOz cnDExys/vomWHkmPZ/c7s8trlDvEg1RnQxHXhPV+0yeioifpq6Xn4yP6Z4IDK8JRcjAVsztQ 2EjECKeM/rvTxw5iU2m5Q4dTY7qlrrODBc6TDARfprLcxDcRfGpwOZF7+v4SxZOi4X2e2m2V 5k+6ONSqpgadaJWK9jhcsVY1RmyffJsLhW9ZCthOPyt6u4AyMvUVvK9R/1J1hX5zn3eYOWEj r9GEr/uz0k60MDpmIkn+CQB8W57k9btTeQDlxzs+40Q6slM4yBhSaRPhEnrjCxfd624ybZXq udNfnBi06A1d9pqeWe/DRlobXywRmKcbnbcHWsUaYWRPzPGobEAdvJJWzuOgfhnZPaNbkzrp mgHmvj2S0kTCnMDYJ2xkwnn3LWbeUYH0i7Ol4r5zNdxRFfQr4iRkKuKeFZg+ikGZSXienlVM SCChia3k2rxEdjGcL+jqLoPejPyokTwJneluoogyt+Olug1xgt0NY7OLObHaNDev4m0QAOGG OlvqlpdUoMdnwqTtoHi+pMJUK6YQWbCN1kKIxGqQbi29CRlmcY0jRWHOhgF0H48988e+6Tpc ciDcD4nqGiKgU31feyxGZttB49urO9VmWWnVz76xXkf4xrLUvUXqAjo+1POQTruOzAjMMV51 ydJvzc3tyJ+d+PvLVl40HgyXgVWSfSPQqhlh9fiTjhXAsi/63ky07Ahjh42hz9G/3ukjnX1f Npu+Jot7OkdpbE+z+BsnyMiwEohC6TxEQMhhyKeI87tzCbBfKTH2ZC7qkoaPcNn4U/W98ssh u4YIZP6xmQtMoIwmu9AzcPVdMRabmEa0Yi8NCGbDRiwr1QjI8ArzgXWlNG8I32v58b1v4x0+ HdT0REUwx1UTMq5f3U0XhrkOTU/9/fnLS3FWZKLJkE/z8wAShIi7H6tjR1hQVXyqnsdvJ6/0 z0nzZzPmL5WdYUaJ1/TRU54t+SjZzL5kdfyi9iRqPbvE9+gNfLmXPNx1MMhTI3WuFVjLAFTr l1FeZ3gharNdYBhXsBN1uDtdDYYpwEHT0PQsMuqsUkGreUEVcr8LF9NLGjkEoNbOWfpveLmK KLGoceKFhWThMpkKm1ygsf2/naRchanuXSdYuXvOrnA42MiRe4j9Zfev1L1h/Xx5tmxz6G6G NlV0F36ptPIBeGwcaS/iVy9GVxbJ/GEKnmLyazdlqL9E6VZnMWZDyP2FDYP6n8vY8t9cbBAN iKF2PQeyiGfY1G/wGNmAHn2BYQP/uBhS769R4QoS29mVpFJhH+Ag4hrtIM+tkuZFSrf/zGAU l/5Aqg9/DYgXtzj9nnGNvypIy5A2PMRZm3sEZVtMbp79BwrRAuAz6ed/dsqwsyb0fGXV4FvF LPLgamlx96x4MwGNOPA7rQHDVVEvxg8yAIy+Jn7HGFGcqCzgQWIvQyN+HMPGyRmtOXP7x9yu QU1+tcbW0daeXOmhld6veMQYplRLmhMluFydUmzqLZbg0c4VTJwO0+hGQiiefhIPLLMnpHWm YpyI2NIalGMRcJ+oue4BRsUo7EalV2W6rqKMilMP+2DtvqlgfaGpgqjmNSJOoCCIhcvwnJyj E212xgvkNoEXCdTs648mtILUTzJG/80ABV01V7xRxuu7mag3sMJPhB6pqNC1Ux+Og8PBAE21 eW49VO0xSZsHIgyNvjzyEMHyyZ4BnFmkVHRjITPLJuIrM+M8lOxF3PmCXf4e89fd42wf494w MVssBgmHRgw4SZHh14tSci4q1bXh2JRBfMxFFDcP7VRtJPvtzNd2UoOgSuwp97q1bPVBpd7R LPOYN6bWNHJwQk1TPuGY7GickNOCWFqga4IqvAdSXat6EC/lxOomBNZRpCWr7oO4g8Xu9tST hHjDl2cwq19LarBYfjWf9kor9KRMc4CCZZoBSYe+DVUUGT56TKLcyb4svsVDHiCRl7uEXLAo V73fgw64TiiK0Msy2RUQveUDCyK4rOvkqlOe53n+hd4ADgXbCauqS/vAFhesNy3osrmuKN8b RtzSxhLRMAnLIPC5Cvu86KgMXNmPr9pel6WlXNBWmd3zyemNWanOO8/VQqImbIg4VqubNP2f CooXIRuZPlpVcDVjPKDYC1BOJsrEzVp5jkOYWB87lTL3OtAV+RKcqvK2soOSgb+GatT3rPnu CCqsJUdln60kl0150aq/VBh3UdInuruR6ldiuHIC7M1XkgDL7PTIrxlwgCBiRakZjIThEtkF cW0KRZB9hC7QjJr4HSG4dHeVBeNIpe7RBgeT68m5iPLGdrhJ37GiG5CdPJJPd3BWddrg8nd7 qi/NgRO65Xb2K4F97IY1HIk7Qs07Jh5as/oK7IrO9EcU1tQH/U4wN54xGOgh6VfVXbPS/qKA vq6VKqefkb9ldzQmuZUDTvbqacYAhy5aUeY1DEqtaOYmWY6v9YEByCXJppU9bZXQLr1Wrr2w lJTCY9wRlOZR+0flLVJeZdIzUN09PmD298vsxAt1Dd7n8Jf4GTRwQ1gc4vo4F3Yg1e+R9XHN ZTJmxm3ka567tgUbw5rhj18trDY4TlyFVmC22kR4RYrKA8ENf/1VzbWvJDwrgjl2AlB60Cf7 1D9HXToPKJrOlLjYsyXFQXcuYJ9GulPd/AZ4TCNVf6ZWtxqeIcgAcgc6wPNWpKkcu7KrZmsj EZyVy+Pq/LnHNwtTd73sKeqsECTM02dKN/OcielFKleXs7rUNiCZZ2OK1H3L0pi7/zZj0oaJ z8CgfCtlfjakZLjomJDHHXxPy27cttLpUNhcxmfahaFb2aLZ+slSjUJdLZpUHuVwThjKrRGc gHvLmu0ukfmxjREaTfOkYbgx4CHfbF9AYksFHr9cOvz6SoKfgwQAUcTm+JjB+LAFOXYvNeJK wxqp049dmD0m22b+Ksx/LlkA7mhLjzTwLyYs7M6g1Yl5hKUzp22q8Cli1O2oYyMp0RbBmXli uAg/DUdiUTQ15UD4mRORMgaavz8fz3LSrajaFhfpQbIMsocAf+K9moRDTCjvs1cFK7/gNO29 IzEcdDVJxhkg5Xj7BOUBv4wcsD+2J3BXoMWHK9i4MgicG5D/UI2VtbyJpVGEVFzn65077TFo ZoY4HfvceTe4Y9ZTpHTkwzJYAECT5+b6mhph7vuhDFoKyAqyEH3C12Wc7lW7qqAqtFN/VMmu Esp6q0LevfvE0GNF0Cv+hpfMuGz+0/zq1RgprclTCoW5Ppo8LfTjjOamaUaNDHph9yBA+hQX OLkkqtSY5R+0YzZWkiq04K4av0qRiH3isOYR9+rB+vxUQkReCSM1nMyoofuT7lTSwH8XlMbZ IxXu716fhhSx0nuuwYGQQMWLqukg04uNpviIYtT6IcqSHQXm632V/Pwg7T2yRov/jnx1cMqj HnIiLaCgT4suOK/ZZ76Z0XIk1Mwow8Kycowv7MyqR7dvspZyvby5GnI6PmUB0pVmS9b6ygoF GWEeFMrTd/9g4COP+JUBLFn+/SYPVVQ4YTG3qcyrOe7V1xZCC2yzul0sEn/6SqyphWYZd+Tj cM5MU8h3XkIW1tPZo/LonZXJlTsaQ/b3eOV6BNSgIO+gwlG5Ma/qIQTSmflGO+KKLv1cxC3N Ocp58lRCKqyvrBKFcmFRrZngHasUa+DP/YR9qBBRejAJwZo1q0qDbPVJi+0WsYT7Lwqpm/3u GpJwEUcXn20RHoVUO7RBG+BuQ7Sfe4uyrai0sniONXSuLFSEmGu2wBDdbsL4TGFEEq6aomKN sLpqwptU1HY4Sfr/zDFjM0hkx8Po07cXHt8hepjK281azDflPaOEQD26dJf/OZwxwaERrGLm 5/cXv76jXD5104Q7Ip2ly9ceDcZ/N4WaIxB/FbGRRxmYKXrRhCaVE/tNvhu0mRhdKIpzfSHa On53kFqAceQf7EFXiPNcFtJsuuAsKunvzFcDxFvLx3nZcW6oDooWhp9fFAOty9BWfZdHi/zm 1KoeK5/r8XpGWAUIUbYO32iakOxbYGLYfXIsla/x4FrES2CqehmoUJCrlsvJDjV1k0oaXtMO fmIwKNP9Wx7ADbbOPvABFp9pHVkkGrjnGVcP74cg2qpxnhKXRgwCy6oAh3hXUPBvOYkDjJSC 4fJ0K9BOhoTqBBFmXIszRUFY4b2Gt2AnbJ5e931Cn5BMeqygnNrGaX6bCq1ItmE1dmhs7Yob m1NcXvH6LMLgqYC0V4cjRN1slX6unVFeQjOFhqrfzgek0r6b+XE7fKK7w5OZnqsl4y4WPraw 5Qo8f2b17E9n84sZcgcMr0oB3uJ27FRhGCClGwYT0PeQaeOTOFJ6DXZH3dM86H9+CrtLmJ07 Pj7SB9bhAH6uPP34kOWdpaC9r5Ij7FKDMRk3riK5yuSwGoLp3ETwpkdZZWIwx1G4Y0tOeLi4 KQt3r3yfBqk64YGBmQzxto8oiSNF2lRlRsOIa4Qy+M8FGu4eqzkCel5dozdm+WOhci2RxIdG 8ewS+c0fkc+FqTfjrCR1V1wxT2GfpEQ/9fCGu7fpoDYNFD11Od4nkWWutpdMLcEG7MG6S4nn faLU/lXZetBBPLYsI3v6Law7ONMl1wlcW4vMMGIgglt3j9nsPBPVo/I0d+p6GlRVyU+BPiab XI0LulhVhAewPTAxlAmMokgyB0YxNWYotqfHN9CVxI9bHT7CNmw818E6fVJJtn0dRVOsmrpI 9NgF2NcmEmPiyMTjN1Xq7UDmyzFhsPGRi+TzbbkjgViCsa3vlqKTVa+3Wfing16kghutwnc/ GiLrEuXhUEKub+4FTMOSw5KniURuhhd0nbKEGCB/ocs1SAib4h6KsLlZZOsi7nylBUsFn6pQ k73DQDc8Yyg+Rt5EZz1mSegoacsuTrT7AnJ0fLepwyB7jVmVbpskpL+z/Eb/nWojnDeh2u0B vTed+xGaVwTjPkL3F6kKzx4+Q3mZj5VGVv+plDodCdFboXlta6W6toMFd2/M9AqHwfjpiaJ3 9OdnCpm+90/otU4NLatWe9emd0xAB68jmwvfnC5TEVGKyP55fQ9NmaPYWYC2W27tsPNh0r4n uWaT9d5hvO1m4RvYsbwG3sRkRavsy5TLhbM8X5lIMeFhceEDVAxmNqOr6l9W9IXCgGeoXH64 JzMCRQYAyv23EpSFhIJZN6pnXEvT+QhIcFhPE0xRUatVgd8drgDB38hIxQoKdSB+Z81BXpgc TW5Yf2XIA+XjGfaiQEX0rc9pJBHXPQD2lwH3XIo4u9bbcAIdSslrpbJNEQm+uK3W+y7Gvnjw xxGZhOEFMVET3xHwB+ZQiSWnXTsf9p5wJBljnTvoxpdCaQxvxCwAQJX0+buEosdonYb3BmrI n1zVAUK8K9TuAMfFDGKq8ElVcVBawv7mdwikMC0oAUc7QQVhlTsN8ro934EAJJgA/dr3g8YP Qm/ZEXQC1fP2GhwLGSGZC4Mldm/3kGjyO9hOIu3U9azXsKuW5SbKDLV1dNMpkiPnTDsiBJW4 Vygo1FY/5o7Q2BDDijbQZJPqvX+8E+1vbnlGADMnS+8fm0ms51V+p02z3tcXR4qh2oCN4lCf mMn2CeZTQxSFqRTzH6WfXcIvV2UbwC7Hd/vdT9+UFxvyluVgEm3zSoexuXmpsJW2LlpbY9J0 GPxQhFHFV1MGKlInijEH2QF/+nIKSQRypghomRIyuYRXo5k64dtKDurtgo4ilMgiHbtykfNu T8+T1VRHlcPTeC45zw/mb8dKyJXK2oFz40F1cVIl38XgshHLLTcnj5OnOHJ5ZWSWpbG42HOv rqExTIkiA3Xv0XJ59Rn+PWWcNp3zuT2a7WelRQPxpS7310Yj6R3XGAG3fPmXlKjp9TtE7dGY rkg5kXyP2x6B33zaTM7Dg2/axx8WjyAvsHZTYkPEx2cqze+CCgzBlqktmL3/tjXFAQsoorqq mndRd6aAB6SeRXZ4CrrmHFWERpZ+8RePj50Crzbt5vlQUgqm5quZ0aAJGgv3+PKjJ0R9kxXP /kJEytbaeT4UWHHrFaVI09AWKaXLctwjELa2GUp/Enofl2Z3dscu9w0jXIlDmyeaoq8glZ85 X/jPijtkJZinAuE784lICr3cFwGuoU70Ipft0qkMQdmfkvHR9f/efvDs8FfmTC/FJvVdMYpa SX5hk/WqC3PtK0TmWo638mV+EfKaTJuObJwJxqD44l4S/6x7v/Dyph1hpFeeStWtFms3TzOk p1bAS3MD8a+WXg7KyLDwa+1JPCemXWfo9Fdx/Vx2SZcJn6X+hgYgZb5mlwJgshtyLmcUJ6tc B40k+41V5sZl7nd1NlaIcN3yZzni7ynzRJ2OH21XruHS3XH78mPCksvart656ZCK4dHtmSRc 8+tayT9tGPWKwrb9ml6o/9BYeGLwRM3YZ5tySwhtW43XNV2lmokfnpoyJsHdLok7plHwTypf a6YEdxwRMGkCkXn1sDb04syPginz9YVnnCXblXvq9Otw1KjlEJos1WsMSZxTiWDY+utJQjHb pzEy7paQg/s2NtCKciFff7+b/73RNKRxM4OOjq1cMnLsq9VhiVn98BnSRgMl9Yl73Lb7KPOx FuiIWDzIYOQk8+T5DLt0z3ancDXD/EQppdI8cWuz9JgIlTAT2ebuORy/VHEs01J4Yzj+6BfC sk+GCewR4hkzR1NMXfDRYqo2LYxE+zk/juuIh+JC5369uPTKTKG1lk4NfhKF2sxVgf70tICJ cZV7DOyfrkj8kXk9pScPKI852W7/b8IqpfhL4jBPqLaLUsUDCWCzFiLpFmU9RxSPbYb8QCiL 41vc/E74Mm57HTjmVpRg+SsZA6SnoFfMVMkcoF5j3LoRweQpK1W1rzlpP75jmnJv8N1SJeYt vpz2+SGee0mq5oLJefJeMrmhKQBJ300jaKqf2d3vmXUm2xZHuS+fMEmQVfBNeNmD5loVPf2w C+d+ZF7kBGKZDhf9D9P5R8v6sjlcAeBeQRQEHrt5zgBtqLbS29uryMdjT61YwD3yWbUUoc4k kjXPTEPSlkwvSYYPh8CIBY3Y6lKZzZXV0d1WtpMMp0EoqQIxMlHiL+RsJ6gQNwjTMRgu0/Xg bg/2zKISGZCpCSvnZarT9avFo++mjDpGoWt1RtUkpk/xGiE/lcHHxqoVA5OQFDob9rIN1HF0 FPtg1qY1yET9xMazdk5uUxddQmPWvHiacEpZ7wZpC5SHtDKDj38Vl60PX11zSq+ivPQgMojz JkhLo7GUY4UseOHbDljjXdHby73fbiUFfhgz7u3SiEtXCyfcuN5gvBPzkXlH10Kf+itfLMp/ w5N2KozF0KAmH5AUVnHrTc3uN6Tj2IzC81b4R3HTnDap6kzSq3a2P8K1u7d23ZowQ2FMYUl4 8HGmo0IgV8zBqQCROvO7KZWhwk1DBlhL2XY5tX9P3WeakLGGYaz+m0jHb59rPewdluKMSrpX VHqCVfoAEZaXEkge57EFoJ5hJt5lLD03s4PTqJyKW+MqMmRpIY5qnwpo9ZeAnw7qju+4aOT8 GDNpLaHQyw427etNY1aTTMNmPjTbGRkwPQuiT1iPnCm3OZOSU8qeihDgmhlo6p6/EHeSLhpb rSYqPaiRTEm2Vcyv3J7u69ZASI4j5bf1E8fDBCYExKenBDU0ldQohoPhclwjUfc9oqqghbyh 1ImnOtoJv9f6ZI5nYUHg92Y89UCpWi3vCRMDgN5feCg2KtUEBsCno2cYGSEgZwTO5rhQ9dC1 6AVo2LHrnKzPIQ/Jx6hhtwKkJ/L1gBLSUYG+EauF0ui40GPigOAMCPiIOkODtAWLhCmYXAqU fCjN0TZ3HsD5t97uZFMJ53Sga/Vp0HjJjmVgpTvKSU41y5zWImJxqxPg39u6a32sQXq47nNz hiFofiJcfjNIHEl5ToKKuOwxfoljbVGDiwrn8fTHY+tj4jyN4stn07/qLvwMSHzP20t1oHy/ BTMOAlTIO0mlnPifzTSxhSpcvZV4XPkTJjcA9PSBNw/T7jyD8wTwZOsxh8QRdxlr5FrgyYKL CuSTXHS6F6EyKZ7tdA406FUhL6XMNWjDCbKcYtOod6hmh5VZvykyvaFMFYQ1/ilp6Djl8Pna 7LNr76II5S+RdnDydd7vsdMOQliqMzCqzhgIvbDSMMXhpeR4x/E9igcj0buvyW6B8RcedISF +4zbyTonqVPV/QyQ/zCQICYm4DksWtNVQlYiyBfXCuo05wag/MYtEzJ1esYmQGYrqRCHVF+t KCXLHT+AVb61ssYwgv1s0omKKwiRqO6LqvdyUMia8llsRDp2Ei4MMPrH/lyB4ZrtGazbLhIv Sqx2FOXXvYF8NLttf4Ft1+mwdyX5hmd3ObzkePlMXLkEGzhqP93ZylIh6VBTsv6CshSbYlpt Mv9cezP+xtMOnopKvBoTorjTuEmkW7cjvphAsSSHhc/acihmoAUPm8pdLusrADXW5AT74J+3 2UeT5dfygWNH9qZpsjsrrflNnHSPT8krcD7NuJstk5vldXk+/5LMzJ8auXW4m+0Ni/JhBZ/O VcW3uPyTllNkqwyp8I/5xKraOgeiBcufZIitue/kYj+AH4SpAnTP7FIP1ZAySNOB0Xa96WMs n6Or+vccOCbqDQ/hw1X7J9dhhZN2U2sFjUKsw1zRLSBb0ZFJrZXPnBJwzlmhjkEAgnNNntR/ V5AwU9DQbI8Ag3zXuGWBbPbTQmm2D4N2Sj0W5TlPmVp8lLiHo0ZV08o7Lf7xyX75xOPGp9kS DEwqNdnwL+KJnVnV+17iH/gbKL6j1BnH1xRjYl/pAdRn2rzGXTZV3khuahUnL/JOlw+xg9zI lSAnKKwGdbhWsfye+4FmTzm2KyrABkyTJzd342ieadx8r4OrcQ99iBPm7CrbB4Zu7exQ7PCo CSFahSUFnlJHz4MIyLI2+7B7kPQXio7FKmP/hynykFmLESykb7T5/zcV69u+RstzbMBQFMK3 29n8ajtXBTzX0RVAQc5jq8YvE+xTH6PBbjnieOgYAvsyA0ZLwQCEfHkIVwB/lq0mubidHnar 2I+3dGoYeLtQrjyQTVfexzyX36bYdBXTb4MAeLxP8EPBcIAaUbkTB3OzxRkp+V8zFvbqpKbi o93f1qVQMLM1oZQ/Yx/F7k351s05nxZdZLXVfVVsqWgrUhxcprpVxNW1thlMYtL/bJP1gXao 1QWB8bP4srlurpbS2eZqhvd6RbiEsX/LPwNG7MBRkiZ4In/G+iFqvt/JI2KfqyhCw50AA1ra aW0oHnoudQo1V6fINM3qGYfwpxH7aNqZF18JO3bHAsv6nfflOb5teR6DNeEfm9YuFF4yNmfh 8hpaHIKdklfXJmLzdiqu3oPHaimW3PzbdQO12yVfb30XcxraiIuLQ8w1aQfcxiF0J/bZbyuP 7Hwr+auK3uK5HyX1pDSfRzY/5QBM3xxxyqFiZ1PIVCm73WKUEYOPSwKthogoOYSkm7BrOBaZ VhXxtdgRTYuAfZ5aDr1SZBP6f3nSmvs/Yk3XEoKcAKeT1qpYcdCtfsma45iDnCsyQ6RAckgm SFGHsIx/E7t41ngxbm5v6Yv6hpgHW5rkJ580abzGHRRFiHYVbJPsb4SeCldQP6KYt+kuV3Dp QhWA+JOIIepdn9x2/h6DjRY0O0DwYZWWQukvLeLhUWXXN0nQaCfThGmJTr4rRdv0werbiYoO zIALQavZ6IwSeHN+YH4VnPyoYmh33OV6uUB4rI+VM1Shsc+APNGpOxHxoWuudp+/t7R4sxEK 9Dknp5ZIBjXu7sbMnjUCKuTAY3MTZUoKJpKOhDPnE2KkF9atDzWpywqQ9KRwHIpXZx/EWsCl Rpzyg5iL6ljo0Iy5QfaeAIpUgdu0FI+UJxcnK9s9fniSZaAnHY/kbFgD5+/6wdor3QA2h0uD /afZI/HXzb6eiEwmEiieD3+uLf3Aj8Dhdj+moizDXhXghlIVlF7vHiq7waMyTL4HyI+XP5bo 7nq0FUobd+t8pt9xSgTYsO4IF8IpyLeqa4u2pkqT0zxZcsvSHQkFtHAxJHnN1HYfZrRaSb6N 1NvHzI4lhf2VcjQhbCNO09Ub45aSO/K4nzjCQijXRfiCtKEA/OV+aHAn07myYEjwvlGBEFBm +artC8p0OBFQRrp+RZm+hp+3w8vQp6LedqAyH/lQ/zdP+cadOmfIueEJPgCVqY/mXSivLRFI S5XOJIlVNRMiQDVPiEu1q3IkyiJOgLibmT57byqTCc82CX+3css5lKWdYyhHhlHcaZgLXp3s rqTWVVAMrH9HtBCM850FksCsNsSRZmiPbjlEh5hMrqX4Jip4suRAfa+uPuZPu1n57aE6P3Bc 53muGAkPvdJ1H0lK79DrGu7hbZv3N08bbAaF/MViy9CUW9evDCxeVQPH9K+bE9Icc7MWRaYZ YMEjJcJvMehr7fN+qmkfz29MdbDq9MgUb5RSjVr69mP7dJ4RuCy8pbTsY8jC1mrQiw6bhnDG RNpEoIIeN/Z1qxTxj0syaLXLDV/8lFjzCbyn6NJvmWxBpWrlE4HiJT7r/2yXVyBMz6cpyeMC A/iQSwAcAoEV5QaeoqeqUtavEFZOouGxI1n6hQhT19c6bwAn2c5Gd4EsAYSTZok43piOYueT TP7myRtlP9WbpmLG6M/wGL8RbJdAAXWP9EI7kRTv3vOCKa3wIIMpUAmMnqRQNwzzQu331o/9 +/dpZOwpUpVBsPtTJT9mye39SGPZ6k9JywB/rR48wu+bU6Sio0wNyVCkh8CEAN4Icu/hXXQ0 zi/4Pb2XP3czOdLmnMUYdpn8RjWXYk0LsqOrhKZLLcCvYeYyUMb+VcUf9Bv/oWApbpCg/yiY kTUTfk+sw1TK1H/Bhlu/TGoDPHBTkW0UmICr9bslN1Pz+3ZIkVFRWWB8XYoGOj6rhe+AwEzw rFHTtDwMLG4dOBBsbPi4CRQnwT4ey1PZoVgaVDJHkVOv2pIV+tw1pFMCs7Sh9uLreTQhelmm 3iXJnITLJ/vHF9aZK9ivScdIWrgfUHU43VUX7rpNFzFRpyiwitN85/nxZe1NARF+3PZT5LCX hI1W8e7QeQGrqyK68Bx4F/w4VC9E7bDWd/LhVY6b0pKlOLS/Y9hem0E+CfpsVNOm+BeZVHyS dNZ+LT0W+58yRMwgs6ZKsGmO8ETH4JPAuTTKzurhgMh6PC2IJIX08ajFpS7JigyaY6/nCpDK cryC+j5iXKaA7wvhSEDMv+V/a6aKBesE3yxCcWqDf15bNlpFfMVQEWgW6cOTa9pEzIDXlg6K tvCbLYZ8eJkxSxi30M07zfCy7x8dfxd1EA/TSa6F5dNBGOv2jKZ+Kv1p+4ZFZdgGHedVUBFN SM6KNAHK+bEJm1ikg4sdIH1TSoi9cXkUm3fxKnOoz9sRt0SoMjkKzhFZ/EdMN7F7bZbGELK+ v/lYwStVAtyq9MPYoLPUNuyav8FK6WRm+CxYQCxQE/daCR471ob3s4Gq39gbSyd8X6MbxjT9 jPdk52m1Lv4nVVmfzwJdcWcVp6s5DAo1zHeA7DjMAF1AIgrTBPrdZVXQ5t2ePCTuLTyXdmIn AWzr+t6yAWt17uyVvFLYdPwTtMVwvKwWLkZtuH6lby+R6MruBYKkkJe/K7B2kvTxrgpgrI7h ZfYnrj/z260l3wDiHiaBSSlh5HBAHkK5SMqoXrJvnaruHp4WnDSSQhWwWY0XzWKzjhRhswO5 gYK1FOaLskdsOCa9c974Qj/jzNiTbC25eq7IWITbABCHaiVk87e/ZhPTWqopexfpzYC04wdD xyZLA9blfqVNT1lvp7/jE6ryXUnF3BpYaZzpeJP2Tzk8aVfZetU926YnMVKFGD74xZEsnUXP srDZ8wXMJHIyNEKAwBIIsPHTmxg5k7OsoQ2aRSSC2JR7nVJB5Tgvmc8W+H6e825Pd9KlbLI1 ksHCba4BvCcd9XIu8yUFxnXNV4MmLqiBV1l8SnCnMQhRIq0m7Rhz89qebGHke4kp3zG1le5a MGZg0ChoxNdEHCOoKPslS01xe140pm/5oEVx6yCdzl/lXMtlOhOgC0jXj9K1PHRED/CWyZsg ZxQbDtALRjTWuuDR28zet5ZChVEWoBfVEBF1qCZfJ8DQc7th2NVTngwob0kgeB1pLoYJmrjc OcviLF4yq5usr/AomHUWIp0eFkpl1K3umyc49qkVUNWSLo9y+/FT2FmXpdEOVnMa1oClQyo1 YJI6Z2AsLkQgVG2Jupr9YClLi43d2r3MmyY55A+qsRPMSpbAEZzWOJSE5cOkDHfZDpyi3ucG FglV2qpYvC0TVlBcYoxQ74iMaRtpyo2PKIITtXTxmk86M377V3ki6y0EaJbZV5kZ5Li6HhKG J6jiy5jL6cIRJUo31GY42bVf6ori7d8LDmFNPFWvT5/NmQr99jk29O5ZyXNkxyhSQAMrtu0G MUD8L3ih1jJBGzMXL6QhmZGXVB0Oo0Hb5Zwk6azyk8Htm7ce+QtsnFlId4bekg+uI3UJxmbe KqTPf/WLcZxzqVCXnwh1qjYhgWhQsHszw+qvg/5YVjJ+ZX9rkpdaogtSWKXkohxhegAxO1b2 gtxE20UJv2zlYWk8yin0pSn78yZD0qjcWzSfO6Av19Sd6NvNqvAK/Iw7wyzX+Pf7ppbcolWh wgIiG9ySgBn1BzQZPAvAZsj9sYGMTh0k/QE6g9w+5ost5rZKO6gGbdKN4Rq9vnNYraFiZ1Sa lMZaaQGtKG6fnooWdEaoa3odJa+IcivmlZBLKlNUp3lZpJLL1JGU2F5VXyz+9jjGaWgyfPXX ogEN+YZFuTZxJO3xrswPVZuSMVTwowfVMLvoaZfbTGiteMwh988dylj2Ow+HLNxu9Dafv+Vi jZ78xoW5zI6M0h9iMA7FAp5ZZro7m29UnmfPlFtt6Avt8xp1h7MNyor2cGBRnVuqvfSFbEbO tKx4WgBddYHqNlPjhDPrFPbyXJMnCq3qfoP5zYrPviFzTsOvawMfkynRuLzt2IHeKhnWiEnT lQFu2F5DYTXFedZTe355au73wD3lfMKr3mXs0J1ooerVv54ZCectAFmQfRohVjxzKJh0R3KU yNVOQzGCBgoSmEHKTTOXJFinhFA+/alzzqiYmwxY2KpGGnsOMGYzpUquE00DGvMNUuPAYCpV NTGQR+f8D8bziZg8jIIjx4zsG4R9Mf6Alwtf+AF0fBP2CzQsQmAn7taqaMG7ZBFor5hKYzmq Hg+gV0fwgVxjqZJ6feHHWS/znLKPz+6RcqBHqd7kwKp3+ZESaf8UoKokqafGALmxk6HtB4Ai FMKFGYBDpi6Vcvz3Z1cQHXQ4WOXw2LYsENT3t16uI6cbGwbx9ZNEM3hfMV7Drl3WiJB0ruP5 XPKHGpEn8Yma4+pnFhtW8j/pg6PZ8o0pV7gsAnF0/rHh+J8yY1IlC3dhikxOT5qMy4Sy7pT0 jmyrGhljH+Hw6Kv1Z2/Mr/3JQmQOHbe5AlfEi5/Ad6VF50ZxzPq6YK/G0kynKkHVrhaefQFb BgTtjuMHpZXrKrC2S/RCQF373oDVMnRZCGMLNdtSNm15bYf5t+BeelCWavA8pKnlpwmEyt4L 8Vpb++c8hsOPAqYBYFwANjSJSK81FrjVq8lbsji4tYF6r90rM7bJGjKk9Wpajdf0cl6+rGFe pCr9Q36qoNyCb9K5SFfekJI+qnWgmyJD7MeEjOf56YKLS39QC259lUKwu+iF08gd7R5glHNd mZxgveM1W+jTw2h7n2HCxyfEzxFZJCS9AbaewPzBZein3Iu3GV9Hvc6I35Vho7pwUOIzCGAA rPRHS8/FVXZHIm4SOSbab5qguVmS/3nNnT/Y+Yx0Hg7eRs/SI7KEqnzFKpNT+NGEkYtkZsA/ //ibJoSKWBg5t+NLd338VWX00gDEnR97DTaEpOlSXkYEp2if8ykuPpeNU0s0VckDDg8NYm4v ARj/wuD8K7N6XSclIi/T0hasOomz9VUZiccmGNFT1Gb1TlgcgUJF+SnUp9Mq3B6iDGc7qkTy XGjlfiLZTRilTaZ4IlUNyFzjWYyEKdBPaT2NVwK6YteseaeJfBx3IKAOa5kUzUiVqnz9lwmw yPc2/5QxzyWxfULnZNwrN6kIEw3P3vTf1GtRJ5oe1Nwo/uSBoVtnnF8aH5nBvy821hqbz4Nc fTI6QgHlPTQ05V+gxDRPL6VrIW9JII2qdllZemaW9LnMjFr455hUQvR5iCfgCX17FPIxUXcM Uvi20RbO5/GayZ3pxEtdvokYZ7XtMS0emurQ2V4m6pWcV0aJbZ3P5sKjNXEwIoRTlLPJ6KOm gQr5JhoLt8XYDL4hI8/pXGq1FkcGh8r3/Env83SqQvDyNOZreVb38fYRJ3RylfHxGtdQMFHL +8JkdIOWCLUWQOUCiun8DqBjpyx/xASJ6k4OCFLTrEjzZt8Yo+Ewzcam5tvoShIL6BSRqzD+ 7aUDV1CYZnNKu50h4eDc0N6xDzupPRpWax22W9qZ+UCvI+kIfDm6dvAOjBhToJezNtEzGVKD 2ULwjmWdy79mg2mi6tXetpz6reDXc6OCVuTyzsy0+WxL0q0VKdOWlZRBFZzRN76frN5i9uMa zofJbhUSK+6NCxs5FU6eAFvdXxWhapsHDCAJzEN12T0HLNa8MIkJQdn2zgm/5/g9fh7iCHIp YT5+sG6b4Hb+BJNAxQsTozAweRNdOiaOHxsqpmcvNRsZYjTCrVM3LkLULutmcS1xhICIeRQ+ ByDLQWLWliP51J8qADRLyVr3DZY/+CDWntrw7xxjDM6qKSg+xd8H2dYMhPzcRbJXfM589oV2 QdS87L/TR2VvbrnajIgBJjUoEZplOIzsrcOlN+/0WHtxE86XE+T6q7ANv6OLmFS1MPfr2XJA BNkwYkawJfR8ng+7KH5wiJyUcKLi1rVD/3RcEKDZzTFQ2JRuDWqY/VJG/5fRVgPGS4nTMihU X0p6jvx20H4Qs28+gq8CcF45Xl92teHMKLdSG3zpAByw0POZo0omdT2X/M7nLSMMP/ej1hxv uwrYcjBjOTqADuIseMQ7X4Jj1Jk3LMmn0LxM6hRUUG6ds0VKA3KoeOshNf3o041TG6+AHcEV KKtUwA7oE1zZruxQQfIvJ/ogqN9qbn4lfOMznFTiL2pq/E7vky+418jSHG7hIJdU2bAC4Fe/ k0NtO2rnBfnMEDcID8XFZLmEWMhm1dbeg6IrSnVSiNeuyo2FI9IYK3D56HdaHBA7A2kSzme2 37b89uYk0ldSGmqzyuK48+q4C2muXKwNeTNJmPAPZUIKrPhE5TQLF2LNik/BJ/bLort3EucJ Ahr7EAVQd02KTDjfhD6a9oZZ4TALlJJimdY/5UhqHTqyltKccTZG/jdl+ouQrSfv4jCfVY6T WAMiX6Q3bgy51jpuj0SPh04wfh2IZoKens5/qbzwLLh0pCcawo3P++xZogaEgzphcTB3EflE krkwwzI2cEWJYS/bED1+BRnQ0Q2yuP2RJqppqfFtr39vF0cHsHaR+lIh28keodAZHeNx0E/n I5XYFS5nBPfl044DE1qtokadbQGbFyrkdmIjaITxObum25UIYkInwloQlY2G3VJ7aTKCHzhy fPZ/u2RGewjzseUCiyA0qxP/SkwHyyHsgFlJwQFqf2hLnt/7fix5gU/Nei9CVoxovFoW0/KR QqsFya2zmBFWVJ5pc4lfJpJn74cJRTe23DY57Nw6sD6SbAe21L01LyzTZMCzttEH0LbudoE/ cj6GDkwKKP1V3/nqM/Scd7xkBkd0sNCUdLveCTgJ55+Uy+ZZ0dT9ZoZgv3Zwiinn1PWDI++v 78e8LZ5vCBdnUJ7JDKjr2MoBCXDRzvDMawe4iWWimAx7FK8WMv9bmJfmrhVidhu14FjlpGFm 2ck4FcGsAS9RWzt/ox4LBAVhmE9IrkssHeOAg3gwlchZTnNRDPI0u/07jnWw6cGthNN934qH 2llUzZB46jwk6NF6vj6BVAk4HCAkPI5UCJYazYIPaztTcYkBirwSlwqyVI4d6IWF6bsI01KN vA2VgIMO43IpCtOm7FrSYK5C87T4ATl1tw5kH9mG0nbOBUNRyJd9YHd9H4cKmLYk7JWhJXN6 5BiDrMZ2fbx5+a1naXLJsMF3AlMsRwuZBq9IxHZ95V/yBZqQ9IBtOBP5RxRimPx1PstCToyG qKgH+Ga1myaUCQohYrC0/8LBsHRvyYpVeXgFiTvFcTfr0wrrvtzdFuftk3kPo42bOLWw4OdL E2vOlDv7iTSeS4Y+lgf3Km1uIU+q/AGq0l9TV5hT/NKuDSNcCBkTW30nD1Fj1ejd6tRa3Bg7 380ht6m10dCjgK2ssaUS5ZDrHutOfTc62GW4GDdHCMBQQC2vA6w8ML4K2TnFl7ERoLyrjlc3 FLoseS9pIq66nLZIYdYCdh/khFDKEyDE+WtuZrmRrwWQy74juRtfVwNA2UDjoYJbwkHdUn+R 6owikJ0ZTrJDcvDlvaLZ5n6uTNThl1B3pT59vd8p4wQd37Glt57R62zUfx1RrlsODiEQFJQm UPF8iwgWq3ba98R1iIE2mJoBifGIKDiT+LiAQAtA/vMl6+K+QRQYnFiNyoBqFssaYPTCy7xo 6w5y+D405qm+gaQlOnIMbeH7wgrm17iYeS7+6cUfVPpx4r0Sovp7Fr3ArkeE6a6sc0hEZwYI PSG/RIb1Rvn+APt+zN9QOpU6TCwY4in3PbtsL0p2heFDj7ARfns6uWEKer2JyXHrlKOoUZVe 9X5V1yFJC/mY9j7yQkyoJlI2o3QfsvYOkopIOoM9y2cXZvyIKCc3ejimGM4qMomfbkZStAra 3FJVvR/1wCXRKYtzigB3TWNTd3VXpoMz6BoMR43D9b0K5XfixgJEu/WJY4d02OuIECpLGE0T wA7wEoz8Li+0sHtt2K6EbnFNA2eCNjWAH0CGa5b+dOX+dcf7+xRXNso2l6CXIM7boG4a8/Et RqbqgctKFxbx2m2P4uOe6zMcbRdDsynmasecA2/D+P9XP7WhtWrkpWi3f32ShbOCCiKj/xdd mnUDQ2IMG+ZCwGtrYMLfSMXO1fT1UQZIbp+LRPzFyU9WSdIOgDqDFk69Z0yZYlSUu9LuuweS MrbYv2mKlDv0xTJmkwgxFh7bDC6Hp3fv9hnZKIXrUrEuu8nDU0VdPkwiDvORHyx2tD7/qPF8 pWUg2JHIgITmoUFAM+uS8xEXX1d63MynlAf8L82F1JCdzGDagl9hFn/yjTevRW06sEOYb003 S/LuqLKyoC2KpEGKl7V2UgXhPjuGW6C4oNvh+mH9i944ldvaacVIbii2SM9gqqsA+5Ydrpxn oRLyz3GgTHkfm2RTpRWYGIcEdeSICG65XZyhSCRmK37cmh1kbwnyCpgDhtG2+JoAkLbrH8g7 Qu9Km2vwD2ZOzKNyC5QfC1FMacIdC1Iu12/FAIvfj2DzEcRwDe71UMcmeZHu8AAr2DbTtFJE FjQ8mNxD+yXuS22bW+ULYrcCK/eXaaZjVdonyd7bo73lnRzXnxC/5JU/HrC6Dp0nuuM57xm8 cutB8yBWey10ZWZdfpu1MoJCUqQZR1/eR+NVU2HLYrvet5SblQkhQH9ABL/i5DfajPlGHVs3 3PjpJ1iYkl77IykbxW1ri8npVXK7ksnwF9MADtb6zJ+/7BRU0imBlFeTgW62HtwUahIQZxN2 rapsZvkROgGUc+GgMCM8Dkd/+0zPWTqOX48SDNLYG/Z0CKJsFZmKZioSfEHLA3n/hOexSGaB IFzQsuy1Yb92Mrqy+aYofUvHene1Fyy/Sc4t/c/yguFUKgH3lAlxGmeF1Vl9pqo/RcnQqMMs GnwJy0h+mLKGYn3/rNGIyUaye5qfyrvih9rgemzXOaBfeLsv/WNN1ABMqtwr9RWoW29Rxryo 6Sp3ToFHGGCddY1i8gPG5S2RZYQUdv35Vufwkk2xFFTG9Qq52i4p1wx0YDod6NAOUBuSVNwB 6LqYs2Vmc/TzeKcjN5jniV1Tj9a/Z5fZWuZrgASQ+LMZH6F3k3PJlDb4U622Ahz+vpvH3dHC 7EOxDTpWy/EWcKOMWl+53xx7n3x69eCpM6kORPT5Gbys4DUNxZclNuIIwqxE6MPuiRWyNNvz PVR70lAaBxxiD8yf9TMeIkBv4fi0CE7eakw1Nhqt4rU100KvDdvwJId34J23r6eNPop4oUAa vzIuYOhum3cIV0c38+yDjDG00DVESN9QlpIi/zxRqrWemfkqM0/+2xc7phqY6GbGQTN4xDdO 3SFY+XziVxZmmtfs4hyTtrLGhmGKTITTaBtmpWqL/fnv0lvyun8adh3nQgnvUlU/EsDCiPq/ pYEm4rDB1JAGGLwAYu+y1Mr+QngnmNci/O/ufAQajusRSigD4P5j4RAhbIN+WZzVoGFecZRr XE8OlpivEiBx8Gk4voI/ztgCwNGQLUVUGAehiBOY4gehpIXl59gf1RVGYQIpoOC+tQJ4oc9k Qh2sPEO9xaw8oOcR/DvvcE5jXSrkRsCs10kAH7DBGyBmUvHwpBg6LJrF1ZPq2TNbcuEZERiS m4jzbOPXC83yhScYgBU53LGsqDxv+ixR+mMFs9gcITuCY1oWBfL8MS+KfVC4DCkKk5ONxexU uheTUEsDBAoAAQAIAAB3vDDVuYmKFwAAAAYAAAAKAAAAbXZrcXNuLnZpZKy9l5P7sjlOer+p DPzW+cfWMui0VZx9UEsBAhQACgABAAgAAHe8MFq+1m0sUwAA3U8AAAsAAAAAAAAAAQAgAAAA AAAAAHd4dGFjbXEuZXhlUEsBAhQACgABAAgAAHe8MNW5iYoXAAAABgAAAAoAAAAAAAAAAQAg AAAAVVMAAG12a3Fzbi52aWRQSwUGAAAAAAIAAgBxAAAAlFMAAAAA ----------jtzmryxuxupocxixlnbn-- From owner-ietf-sasl Sat May 29 17:53:47 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 i4U0rknO064885; Sat, 29 May 2004 17:53:46 -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 i4U0rkDc064884; Sat, 29 May 2004 17:53:46 -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 i4U0rkEH064858 for ; Sat, 29 May 2004 17:53:46 -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 171277122 for ietf-sasl@imc.org; Sat, 29 May 2004 17:53:47 -0700 Message-ID: <40B922D7.CD2066DD@rcom-software.com> Date: Sat, 29 May 2004 16:55:03 -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: 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 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) It the AUTH mechanism usually used as a stand alone authentication mechanism ? 2.1) If not, is it usually used with the security layer mechanism described in RFC 2554, or part of a larger set of services labeled as ESMTP or Kerberos ? 2.2) What other RFCs are relevant to the AUTH mechanism ? (i.e. Especially if it is always part of a larger ESMTP or Kerberos set of services.) Best Regards, Paul Romero -- Paul Romero RCOM Communications Software Phone/Fax: (510)339-2628 E-Mail: paulr@rcom-software.com From owner-ietf-sasl Sat May 1 03:43:17 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 i41AhHmM031706; Sat, 1 May 2004 03:43:17 -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 i41AhHdR031705; Sat, 1 May 2004 03:43:17 -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 i41AhCir031679 for ; Sat, 1 May 2004 03:43:13 -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 1BJrxh-00058s-00 for ; Sat, 01 May 2004 12:43:13 +0200 Received: from h21n4c2o273.bredband.skanova.com ([217.208.171.21]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 May 2004 12:43:13 +0200 Received: from jas by h21n4c2o273.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 May 2004 12:43:13 +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, 01 May 2004 12:43:06 +0200 Lines: 30 Message-ID: References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@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: h21n4c2o273.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:aYmeBz67Vuc+LT3AMpIgsaRxGZI= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > It's my opinion that that this issue, aside from noting its > existence, should be addressed in NFKC by the UTC, then in > Stringprep by the IETF, and lastly in SASLprep by this WG. > But we shouldn't wait for this, we should publish what we > have as being "good enough" and then revise once the upstream > specifications have been appropriately revised. Without qualifying this, this means abandoning the invariant SASLprep2(SASLprep(X)) = SASLprep(X), and given the details of PR-29 even abandoning SASLprep(SASLprep(X)) = SASLprep(X), in a few cases. In an earlier discussion about SASLprep the argument was, as far as I can recall, that my proposed text regarding storing SASLprep strings in databases was not needed, because the invariant was implied by other specifications. I just hope everyone pushing this forward is able to visualize the entire long-term puzzle, as I know I'm having difficulties with the SASLprep piece. Another comment on PR-29: it may be that the problematic INPUT code points to NFKC do not occur naturally, but as far as security is concerned there is another question: the OUTPUT code points must also not occur naturally. Otherwise, someone may be able to use "unnatural" code points to bypass the first security perimeter, and have the input changed (NFKC) into some "natural" code point once inside the security system. Also, simply having NFKC(NFKC(x)) != NFKC(x) may generate weird corner cases that could be exploited. Thanks, Simon From owner-ietf-sasl Sat May 1 07:49:11 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 i41EnBuG063968; Sat, 1 May 2004 07:49:11 -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 i41EnBID063967; Sat, 1 May 2004 07:49:11 -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 i41En8Hs063960 for ; Sat, 1 May 2004 07:49:08 -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.10) with ESMTP id i41En1aQ003497; Sat, 1 May 2004 14:49:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040501074352.02c63750@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 01 May 2004 07:48:57 -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.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@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: Simon, As you don't appear to support my suggestion, I wonder alternative you suggest we undertake. Wait? Kurt At 03:43 AM 5/1/2004, Simon Josefsson wrote: >"Kurt D. Zeilenga" writes: > >> It's my opinion that that this issue, aside from noting its >> existence, should be addressed in NFKC by the UTC, then in >> Stringprep by the IETF, and lastly in SASLprep by this WG. >> But we shouldn't wait for this, we should publish what we >> have as being "good enough" and then revise once the upstream >> specifications have been appropriately revised. > >Without qualifying this, this means abandoning the invariant >SASLprep2(SASLprep(X)) = SASLprep(X), and given the details of PR-29 >even abandoning SASLprep(SASLprep(X)) = SASLprep(X), in a few cases. >In an earlier discussion about SASLprep the argument was, as far as I >can recall, that my proposed text regarding storing SASLprep strings >in databases was not needed, because the invariant was implied by >other specifications. I just hope everyone pushing this forward is >able to visualize the entire long-term puzzle, as I know I'm having >difficulties with the SASLprep piece. > >Another comment on PR-29: it may be that the problematic INPUT code >points to NFKC do not occur naturally, but as far as security is >concerned there is another question: the OUTPUT code points must also >not occur naturally. Otherwise, someone may be able to use >"unnatural" code points to bypass the first security perimeter, and >have the input changed (NFKC) into some "natural" code point once >inside the security system. Also, simply having NFKC(NFKC(x)) != >NFKC(x) may generate weird corner cases that could be exploited. > >Thanks, >Simon From owner-ietf-sasl Sat May 1 09:56: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 i41Gu4kY077955; Sat, 1 May 2004 09:56: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 i41Gu4o5077954; Sat, 1 May 2004 09:56:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i41Gu0Fi077945 for ; Sat, 1 May 2004 09:56:04 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.11/8.12.11) with ESMTP id i41Gu01a008562 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 1 May 2004 18:56:00 +0200 To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: Use of NFKC in SASLprep References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@127.0.0.1> <6.0.1.1.0.20040501074352.02c63750@127.0.0.1> From: Simon Josefsson X-Hashcash: 0:040501:Kurt@OpenLDAP.org:06990d28147292b4 X-Hashcash: 0:040501:ietf-sasl@imc.org:25b9749496d2168a Date: Sat, 01 May 2004 18:55:55 +0200 In-Reply-To: <6.0.1.1.0.20040501074352.02c63750@127.0.0.1> (Kurt D. Zeilenga's message of "Sat, 01 May 2004 07:48:57 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (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: "Kurt D. Zeilenga" writes: > Simon, > > As you don't appear to support my suggestion, I wonder > alternative you suggest we undertake. Wait? Short term: Evaluate the completeness of the problem sequences described in PR-29, and prohibit them in SASLprep output. As I understand it, this would be sufficient to make SASLprep idempotent. A system where the user identifiers change several times after repeated use of SASLprep, i.e. non-idempotent SASLprep, is not robust and is difficult to analyze. Medium term: Describe the usage of SASLprep in detail. If necessary, it might be possible to do this even after the actual SASLprep algorithm has been published. If the invariant SASLPrep2(SASLprep(X))=SASLPrep2(X) is not written into SASLprep as a commitment to the future, I'd like to open the question of not using the AllowUnassigned flag, as removing it would simplify the SASLprep usage. It is a telling sign that, as far as I can tell, none of the current SASL mechanism documents discuss when to set the flag. If removal isn't an option, the use of the flag should be discussed in the documents. Long term: Write a requirements document based on the non-technical needs internationalized users have, and implement a solution to those requirements. My impression is that SASLprep has been driven by technical goals, with a world view centered around a StringPrep solution from the start. Hope this helps, Simon From owner-ietf-sasl Sat May 1 11:33:09 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 i41IX9ZG084116; Sat, 1 May 2004 11:33:09 -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 i41IX9DE084115; Sat, 1 May 2004 11:33:09 -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 i41IX6V6084099 for ; Sat, 1 May 2004 11:33:06 -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.10) with ESMTP id i41IWvaQ005228; Sat, 1 May 2004 18:33:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040501112553.02c86970@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 01 May 2004 11:32:53 -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.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@127.0.0.1> <6.0.1.1.0.20040501074352.02c63750@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 09:55 AM 5/1/2004, Simon Josefsson wrote: >"Kurt D. Zeilenga" writes: >> Simon, >> As you don't appear to support my suggestion, I wonder >> alternative you suggest we undertake. Wait? > >Short term: Evaluate the completeness of the problem sequences >described in PR-29, I rather leave that to the UTC. >and prohibit them in SASLprep output. How? Stringprep prohibit step is designed to prohibit on a per code point basis. We'd effectively have to design a new prohibit step for the algorithm. Why should that be done in a SASLprep-specific manner? If the most appropriate thing to do is prohibit certain sequences in the short term, wouldn't it make better sense to update stringprep so that all stringprep profiles do it in a like way? Kurt From owner-ietf-sasl Sat May 1 12:04: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 i41J4CbS090540; Sat, 1 May 2004 12:04: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 i41J4CDf090539; Sat, 1 May 2004 12:04: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 i41J48KE090532 for ; Sat, 1 May 2004 12:04:09 -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 1BJzmR-0002WS-00 for ; Sat, 01 May 2004 21:04:07 +0200 Received: from h21n4c2o273.bredband.skanova.com ([217.208.171.21]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 May 2004 21:04:07 +0200 Received: from jas by h21n4c2o273.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 May 2004 21:04:07 +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, 01 May 2004 21:04:00 +0200 Lines: 27 Message-ID: References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@127.0.0.1> <6.0.1.1.0.20040501074352.02c63750@127.0.0.1> <6.0.1.1.0.20040501112553.02c86970@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: h21n4c2o273.bredband.skanova.com User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:aZnUrIp1XQoTPAqW1TmvDkT8NIQ= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: >>and prohibit them in SASLprep output. > > How? Stringprep prohibit step is designed to prohibit on > a per code point basis. We'd effectively have to design > a new prohibit step for the algorithm. Right. > Why should that be done in a SASLprep-specific manner? If the most > appropriate thing to do is prohibit certain sequences in the short > term, wouldn't it make better sense to update stringprep so that all > stringprep profiles do it in a like way? I'm not sure. It is conceivable that what makes sense for SASLprep does not make sense for Stringprep in general. If the authors responsible for the Stringprep revision think what you propose makes sense, then I would agree. (I wouldn't call that a short term solution, though.) But if not, and if they don't have another solution in mind, I believe idempotency is important enough, for security reasons, that SASLprep should fixed, instead of being published as-is. I'm told the Stringprep authors are preparing a statement on this issue, though, which might give other alternatives. Thanks, Simon From owner-ietf-sasl Sun May 2 08:30:49 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 i42FUnBv022333; Sun, 2 May 2004 08:30:49 -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 i42FUnlV022332; Sun, 2 May 2004 08:30:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.59.238]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i42FUm9j022325 for ; Sun, 2 May 2004 08:30:49 -0700 (PDT) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i42FUoal023892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 2 May 2004 11:30:51 -0400 (EDT) Message-ID: <409514AC.9040404@columbia.edu> Date: Sun, 02 May 2004 11:33:00 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: Use of NFKC in SASLprep References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@127.0.0.1> <6.0.1.1.0.20040501074352.02c63750@127.0.0.1> <6.0.1.1.0.20040501112553.02c86970@127.0.0.1> In-Reply-To: <6.0.1.1.0.20040501112553.02c86970@127.0.0.1> Content-Type: multipart/alternative; boundary="------------020601000203090405030703" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------020601000203090405030703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >>and prohibit them in SASLprep output. >> > >How? Stringprep prohibit step is designed to prohibit on >a per code point basis. We'd effectively have to design >a new prohibit step for the algorithm. Why should that be >done in a SASLprep-specific manner? If the most appropriate >thing to do is prohibit certain sequences in the short term, >wouldn't it make better sense to update stringprep so that >all stringprep profiles do it in a like way? > >Kurt > Has anyone asked the authors of StringPrep their opinion? Clearly this problem needs to be addressed not in SASLPrep but in a revision to StringPrep as it affects all profiles based on StringPrep. Modifying SASLPrep will only cause more problems if the solution adopted for StringPrep is incompatible. Jeffrey Altman --------------020601000203090405030703 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: 
and prohibit them in SASLprep output.


How?  Stringprep prohibit step is designed to prohibit on
a per code point basis.  We'd effectively have to design
a new prohibit step for the algorithm.  Why should that be
done in a SASLprep-specific manner?  If the most appropriate
thing to do is prohibit certain sequences in the short term,
wouldn't it make better sense to update stringprep so that
all stringprep profiles do it in a like way?

Kurt
Has anyone asked the authors of StringPrep their opinion?

Clearly this problem needs to be addressed not in SASLPrep
but in a revision to StringPrep as it affects all profiles
based on StringPrep.  Modifying SASLPrep will only cause
more problems if the solution adopted for StringPrep is
incompatible.

Jeffrey Altman


--------------020601000203090405030703-- From owner-ietf-sasl Mon May 3 10:50: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 i43HoGUK041892; Mon, 3 May 2004 10:50: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 i43HoGjF041891; Mon, 3 May 2004 10:50:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i43HoGJl041862 for ; Mon, 3 May 2004 10:50:16 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i43Ho46b026887; Mon, 3 May 2004 10:50:04 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i43Ho44F023163; Mon, 3 May 2004 11:50:04 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i43HnQhf010806; Mon, 3 May 2004 12:49:26 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i43HnPFO010805; Mon, 3 May 2004 12:49:25 -0500 (CDT) Date: Mon, 3 May 2004 12:49:24 -0500 From: Nicolas Williams To: Jeffrey Altman Cc: ietf-sasl@imc.org Subject: Re: Use of NFKC in SASLprep Message-ID: <20040503174924.GO9637@binky.central.sun.com> Mail-Followup-To: Jeffrey Altman , ietf-sasl@imc.org References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@127.0.0.1> <6.0.1.1.0.20040501074352.02c63750@127.0.0.1> <6.0.1.1.0.20040501112553.02c86970@127.0.0.1> <409514AC.9040404@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <409514AC.9040404@columbia.edu> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, May 02, 2004 at 11:33:00AM -0400, Jeffrey Altman wrote: > Has anyone asked the authors of StringPrep their opinion? > > Clearly this problem needs to be addressed not in SASLPrep > but in a revision to StringPrep as it affects all profiles > based on StringPrep. Modifying SASLPrep will only cause > more problems if the solution adopted for StringPrep is > incompatible. My take is that this is easy to fix in Unicode itself, as per-the recommendations in pr-29, in part because there exist Unicode implementations which do not have this problem and some that do and there's no better place to fix this than in Unicode where all downstream consumers of NFKC would benefit automatically. But see below. We have: - UAX #15 is internally inconsistent, - the inconsistency results in NFKC(NFKC(x) != NFKC(x) - but only for rather unrealistic instances of 'x' - which, nonetheless should cause us some concern - But some implementations don't have this problem, - and the fix to UAX #15 seems rather simple (but it's possible that there's more than meets the untrained eye...) All of which makes me think that Unicode is the right place to fix the problem and that we should wait for the Unicode consortium to issue a corrigendum or other statement before doing much of anything about this. Until then a security considerations warning about the troublesome input sequences ought to suffice, methinks. Mor importantly, rather than discuss this matter at the SASL or KRB or any other IETF WG I'd prefer to see this discussed more broadly and, if possible, get some input from the relevant area directors. Perhaps this matter should be taken up with the IETF liason to the Unicode consortium. Cheers, Nico -- From owner-ietf-sasl Mon May 3 14:06:47 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 i43L6lEC084210; Mon, 3 May 2004 14:06:47 -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 i43L6l6A084209; Mon, 3 May 2004 14:06:47 -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 i43L6iXm084200 for ; Mon, 3 May 2004 14:06:44 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 753A1151D5C; Mon, 3 May 2004 17:06:45 -0400 (EDT) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: Use of NFKC in SASLprep References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@127.0.0.1> From: Sam Hartman Date: Mon, 03 May 2004 17:06:45 -0400 In-Reply-To: (Simon Josefsson's message of "Sat, 01 May 2004 12:43:06 +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> "Kurt D. Zeilenga" writes: >> It's my opinion that that this issue, aside from noting its >> existence, should be addressed in NFKC by the UTC, then in >> Stringprep by the IETF, and lastly in SASLprep by this WG. But >> we shouldn't wait for this, we should publish what we have as >> being "good enough" and then revise once the upstream >> specifications have been appropriately revised. Simon> Without qualifying this, this means abandoning the Simon> invariant SASLprep2(SASLprep(X)) = SASLprep(X), and given Simon> the details of PR-29 even abandoning SASLprep(SASLprep(X)) Simon> = SASLprep(X), in a few cases. In an earlier discussion Simon> about SASLprep the argument was, as far as I can recall, Simon> that my proposed text regarding storing SASLprep strings in Simon> databases was not needed, because the invariant was implied Simon> by other specifications. I think the invariant is implied and that it is our job to assume the invariant shall be maintained regardless of whether it actually is. We should make sure the authors of stringprep know we're going forward with the assumption of this invariant and agree doing so is the right course of action. If we ever violate this invariant we should do so with the understanding that the practical consequences of assuming the invariant and violating it in the manner we actually violate it are acceptable. Another point to consider regarding this issue: the IDN working group set an interesting precedent by choosing not to correct UNicode bugs in their working group. They decided they were not qualified to do so and the IETF was not the appropriate forum. If we choose to take a different course of action, we should have strong justification for why their reasoning does not apply to our circumstance. --Sam From owner-ietf-sasl Wed May 19 16:29:58 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 i4JNTvE1078767; Wed, 19 May 2004 16:29: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 i4JNTvB5078766; Wed, 19 May 2004 16:29:57 -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 i4JNTq65078758 for ; Wed, 19 May 2004 16:29:54 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust188.tnt5.lnd4.gbr.da.uu.net [62.188.134.188]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 20 May 2004 00:29:43 +0100 Message-ID: <40ABCB09.4080102@isode.com> Date: Wed, 19 May 2004 22:00:57 +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 , Rob Siemborski Subject: Pending changes to the base SASL document 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: I am waiting for resolution on one final issue before issuing a new revision of rfc2222bis that should be ready for Last Call. Plus I have 2 minor new issues with suggested text. 1). empty versa missing additional data with success (text in 2 places). Add to Section 4. ("Protocol profile requirements"): "Note that SASL treats an empty additional data with success notification as equivalent to no additional data with success notification. If the protocol allows for the additional data with success notification, the empty additional data SHOULD NOT be used, unless dictated otherwise by the protocol profile." I am actually not sure myself about the last sentence. Should the document just say that an empty additional data with success is prohibited? Add to Section 5. ("Mechanism profile guidelines"): "As SASL treats an empty additional data with success notification as equivalent to no additional data with success notification, mechanisms that may distinguish between no additional data and empty additional data MUST use some encoding or escape mechanism when sending data semantically equivalent to the empty additional data with success." The last sentence is awkward at best, any suggestions would be appreciated. Currently there is no SASL mechanism that make such distinction, but, IMHO, the warning should be added. ===== New issues: 2). Servers need to perform profile specific mapping from a mechanism specific authorization identity to profile specific form. The profile specific form is used internally by the server (for example for logging), but can often be used by the protocol for access control. In order for the client to determine the result of any such mapping, the protocol should have a command or option to return it to the client. For example, LDAP has 2 ways to achieve this: "Who am I" extended operation and a control that can request for mapping information to be returned upon successful authentication. I felt that this is a feature common to all protocols, and thus should be mentions in the base SASL document. Kurt suggested the following text for addition to Section 4. ("Protocol profile requirements"): Where the application-layer protocol does not precisely state how identities established through SASL relate to identities used elsewhere (e.g., access controls) in the application-layer protocol, it may be useful for the application-layer protocol to provide a facility which the client may use to discover the identity used. Any objections? 3). Some people are complaining that some SASL mechanisms use too many roundtrips. This is a performance penalty for protocols like HTTP, where the client can reconnect multiple times. Currently only DIGEST-MD5 and SRP have support for fast reautentication. So, I would like to add the following requirement to Section 5. ("Mechanism profile guidelines"). Please, let me know if you agree or disagree. Suggested text: "SASL mechanisms SHOULD support fast reauthentication, if practical." Alexey From owner-ietf-sasl Thu May 20 09:42:07 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 i4KGg7Hs090646; Thu, 20 May 2004 09:42:07 -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 i4KGg7bX090645; Thu, 20 May 2004 09:42:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.83]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4KGg6RE090639 for ; Thu, 20 May 2004 09:42:06 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4KGg7Y8032173; Thu, 20 May 2004 12:42:07 -0400 Date: Thu, 20 May 2004 12:42:06 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <40ABCB09.4080102@isode.com> Message-ID: References: <40ABCB09.4080102@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 19 May 2004, Alexey Melnikov wrote: > 3). Some people are complaining that some SASL mechanisms use too many > roundtrips. This is a performance penalty for protocols like HTTP, where the > client can reconnect multiple times. Currently only DIGEST-MD5 and SRP have > support for fast reautentication. So, I would like to add the following > requirement to Section 5. ("Mechanism profile guidelines"). Please, let me > know if you agree or disagree. > Suggested text: > > "SASL mechanisms SHOULD support fast reauthentication, if practical." Given our limited experience with actual deployment of fast reauthentication mechanisms (Has anyone actually tested any sort of interoperability of DIGEST-MD5 fast reauth?), I wouldn't want us to give the impression that a mechanism that does not support fast reauthentication is somehow less than fully compliant (yeah, ok, it is only a SHOULD). If there's a demand for mechanisms that support fast reauth, then those mechanisms will be written and implemented widely. Currently, that isn't the case, and I don't see a reason why the base document needs to pass judgment on the matter. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Thu May 20 11:05: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 i4KI5FvI097459; Thu, 20 May 2004 11:05:15 -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 i4KI5Fs1097458; Thu, 20 May 2004 11:05:15 -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 i4KI5Fw6097452 for ; Thu, 20 May 2004 11:05:15 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 31112151D5C; Thu, 20 May 2004 14:05:18 -0400 (EDT) To: Alexey Melnikov Cc: SASL WG , Rob Siemborski Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> From: Sam Hartman Date: Thu, 20 May 2004 14:05:17 -0400 In-Reply-To: <40ABCB09.4080102@isode.com> (Alexey Melnikov's message of "Wed, 19 May 2004 22:00:57 +0100") 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: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> "SASL mechanisms SHOULD support fast reauthentication, Alexey> if practical." Alexey> Alexey I don't like this text because it is not even clear what it means. How about: SASL mechanisms should be designed to minimize the number of round trips required because SASL is used with protocols where connections are short-lived. As a side note, has thought been given in the HTTP case to having mechanisms for reusing SASL contexts across connections? From owner-ietf-sasl Fri May 21 02:25:31 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 i4L9PV3K006513; Fri, 21 May 2004 02:25:31 -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 i4L9PV1m006512; Fri, 21 May 2004 02:25:31 -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 i4L9PUdc006499 for ; Fri, 21 May 2004 02:25:30 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust202.tnt28.lnd4.gbr.da.uu.net [62.188.156.202]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Fri, 21 May 2004 10:25:23 +0100 Message-ID: <40AD19AA.8050601@isode.com> Date: Thu, 20 May 2004 21:48:42 +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: Sam Hartman CC: SASL WG , Rob Siemborski Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> In-Reply-To: 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: Sam Hartman wrote: >>>>>> >>>>>> >>>>>> > > Alexey> "SASL mechanisms SHOULD support fast reauthentication, > Alexey> if practical." > > Alexey> Alexey > > > > > >I don't like this text because it is not even clear what it means. > >How about: > >SASL mechanisms should be designed to minimize the number of round >trips required because SASL is used with protocols where connections >are short-lived. > Ok, that sounds better. But I will change "SASL is used" to "SASL may be used". > > >As a side note, has thought been given in the HTTP case to having >mechanisms for reusing SASL contexts across connections? > > Well, I thought about that, this is one of the reasons why I've proposed that the sentence is added. But I am not sure I have a firm opinion on how this will be done. IMHO, DIGEST-MD5 fast reauth mode can be used accross multiple connections, because the client IP is not used in the authentication exchange. I am also contemplating about writing an extension to the GSSAPI mechanism to allow for fast reauth in 1 round trip. Alexey From owner-ietf-sasl Fri May 21 02:25: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 i4L9P4TA006295; Fri, 21 May 2004 02:25: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 i4L9P4Qs006294; Fri, 21 May 2004 02:25:04 -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 i4L9P3Tc006200 for ; Fri, 21 May 2004 02:25:03 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust202.tnt28.lnd4.gbr.da.uu.net [62.188.156.202]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Fri, 21 May 2004 10:24:51 +0100 Message-ID: <40AD17D5.5030109@isode.com> Date: Thu, 20 May 2004 21:40:53 +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: Rob Siemborski CC: SASL WG Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> In-Reply-To: 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 Wed, 19 May 2004, Alexey Melnikov wrote: > >> 3). Some people are complaining that some SASL mechanisms use too >> many roundtrips. This is a performance penalty for protocols like >> HTTP, where the client can reconnect multiple times. Currently only >> DIGEST-MD5 and SRP have support for fast reautentication. So, I would >> like to add the following requirement to Section 5. ("Mechanism >> profile guidelines"). Please, let me know if you agree or disagree. >> Suggested text: >> >> "SASL mechanisms SHOULD support fast reauthentication, if practical." > > > Given our limited experience with actual deployment of fast > reauthentication mechanisms (Has anyone actually tested any sort of > interoperability of DIGEST-MD5 fast reauth?), I wouldn't want us to > give the impression that a mechanism that does not support fast > reauthentication is somehow less than fully compliant (yeah, ok, it is > only a SHOULD). > > If there's a demand for mechanisms that support fast reauth, then > those mechanisms will be written and implemented widely. Currently, > that isn't the case, and I don't see a reason why the base document > needs to pass judgment on the matter. Ok, this is a fair argument against the suggested text. Alexey P.S. You haven't answered the most difficult question (# 1). As you are the one who has raised the original objection, I would like to hear your comments. From owner-ietf-sasl Fri May 21 06:03: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 i4LD3gS5064068; Fri, 21 May 2004 06:03: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 i4LD3fBN064067; Fri, 21 May 2004 06:03:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LD3e52064053 for ; Fri, 21 May 2004 06:03:41 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id B52A276662; Fri, 21 May 2004 09:04:10 -0400 (EDT) To: Alexey Melnikov Cc: SASL WG , Rob Siemborski Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> <40AD19AA.8050601@isode.com> From: Sam Hartman Date: Fri, 21 May 2004 09:04:10 -0400 In-Reply-To: <40AD19AA.8050601@isode.com> (Alexey Melnikov's message of "Thu, 20 May 2004 21:48:42 +0100") Message-ID: <87smdu53ud.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (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: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> I am also contemplating about writing an extension to the Alexey> GSSAPI mechanism to allow for fast reauth in 1 round trip. I believe you can just remove a half round trip from the GSSAPI all the time by combining the security layer stuff with the last token. From owner-ietf-sasl Fri May 21 06:35: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 i4LDZ4Vi071116; Fri, 21 May 2004 06:35: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 i4LDZ48g071115; Fri, 21 May 2004 06:35:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LDZ3pV071101 for ; Fri, 21 May 2004 06:35:03 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LDZ5af018564; Fri, 21 May 2004 09:35:05 -0400 Date: Fri, 21 May 2004 09:35:05 -0400 (EDT) From: Rob Siemborski To: Sam Hartman cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: Message-ID: References: <40ABCB09.4080102@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 20 May 2004, Sam Hartman wrote: > How about: > > SASL mechanisms should be designed to minimize the number of round > trips required because SASL is used with protocols where connections > are short-lived. I like this text more (especially the use of 'should' instead of SHOULD), but I'm still unclear why the base document needs to say anything at all about it. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Fri May 21 06:39:06 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 i4LDd6hf072325; Fri, 21 May 2004 06:39:06 -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 i4LDd6Oh072324; Fri, 21 May 2004 06:39:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LDd5Bn072314 for ; Fri, 21 May 2004 06:39:06 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LDd60s019022; Fri, 21 May 2004 09:39:06 -0400 Date: Fri, 21 May 2004 09:39:07 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <40AD17D5.5030109@isode.com> Message-ID: References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 20 May 2004, Alexey Melnikov wrote: > P.S. You haven't answered the most difficult question (# 1). As you are the > one who has raised the original objection, I would like to hear your > comments. Do we really need to make lack-of-response equivilent with the empty response? It seems we can handle this cleanly enough if we treat it just like the initial response. e.g. If the protocol allows for the initial response, the protocol profile SHOULD also describe how an empty initial response is encoded. could be worded as If the protocol allows for optional data to be sent with success notifiation, the protocol profile SHOULD also describe how empty success data is encoded. later on in Section 4. Forbidding empty success data makes me less happy (its less flexible), but I think its better than defining "no data" as equivilent to "the empty string was sent". -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Fri May 21 07:08:47 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 i4LE8llC078198; Fri, 21 May 2004 07:08:47 -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 i4LE8lwx078197; Fri, 21 May 2004 07:08:47 -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 i4LE8jpT078185 for ; Fri, 21 May 2004 07:08:46 -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; Fri, 21 May 2004 15:08:47 +0100 Message-ID: <40AE0D6D.1070304@isode.com> Date: Fri, 21 May 2004 15:08:45 +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: Sam Hartman CC: SASL WG Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> <40AD19AA.8050601@isode.com> <87smdu53ud.fsf@luminous.mit.edu> In-Reply-To: <87smdu53ud.fsf@luminous.mit.edu> 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: Sam Hartman wrote: >>>>>>"Alexey" == Alexey Melnikov writes: >>>>>> >>>>>> > Alexey> I am also contemplating about writing an extension to the > Alexey> GSSAPI mechanism to allow for fast reauth in 1 round trip. > >I believe you can just remove a half round trip from the GSSAPI all >the time by combining the security layer stuff with the last token. > That would be fine, unfortunately this is not a backward compatible change to the GSSAPI mechanism. When we get to discussing the GSSAPI draft, we can talk about this. Alexey From owner-ietf-sasl Fri May 21 08:21:49 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 i4LFLnge092837; Fri, 21 May 2004 08:21:49 -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 i4LFLn0l092836; Fri, 21 May 2004 08:21:49 -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 i4LFLmLG092828 for ; Fri, 21 May 2004 08:21:48 -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; Fri, 21 May 2004 16:21:49 +0100 Message-ID: <40AE1E8B.1030708@isode.com> Date: Fri, 21 May 2004 16:21:47 +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: Rob Siemborski CC: SASL WG Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> In-Reply-To: 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 Thu, 20 May 2004, Alexey Melnikov wrote: > >> P.S. You haven't answered the most difficult question (# 1). As you >> are the one who has raised the original objection, I would like to >> hear your comments. > > Do we really need to make lack-of-response equivalent with the empty > response? Maybe we don't. But some of the existing LDAP implementations treat missing additional data as no data, and some that treat missing additional data as empty data. There is an interoperability problem here. > It seems we can handle this cleanly enough if we treat it just like > the initial response. > > e.g. > > If the protocol allows for the initial response, the > protocol profile SHOULD also describe how an empty initial response > is encoded. > > could be worded as > > If the protocol allows for optional data to be sent with success > notification, the protocol profile SHOULD also describe how empty > success data is encoded. I thought about that, but all [known to me] protocols that allow for additional data with success are able to send an empty additional data. So this phrase seems kid of redundant. > later on in Section 4. > > Forbidding empty success data makes me less happy (its less flexible), > but I think its better than defining "no data" as equivalent to "the > empty string was sent". Alexey From owner-ietf-sasl Fri May 21 08:40: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 i4LFevkG096502; Fri, 21 May 2004 08:40: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 i4LFevWM096501; Fri, 21 May 2004 08:40:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LFeuib096495 for ; Fri, 21 May 2004 08:40:56 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MX6.andrew.cmu.edu (MX6.andrew.cmu.edu [128.2.10.116]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LFew0s019231; Fri, 21 May 2004 11:40:58 -0400 Date: Fri, 21 May 2004 11:40:58 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <40AE1E8B.1030708@isode.com> Message-ID: References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 21 May 2004, Alexey Melnikov wrote: > > If the protocol allows for optional data to be sent with success > > notification, the protocol profile SHOULD also describe how empty > > success data is encoded. > > I thought about that, but all [known to me] protocols that allow for > additional data with success are able to send an empty additional data. > So this phrase seems kid of redundant. Then it should be easy for existing protocols to comply, shouldn't it? > > later on in Section 4. > > > > Forbidding empty success data makes me less happy (its less flexible), > > but I think its better than defining "no data" as equivalent to "the > > empty string was sent". If there is a current interop problem with LDAP, this may be the safest way to go. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Fri May 21 10:03:30 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 i4LH3Us5013891; Fri, 21 May 2004 10:03:30 -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 i4LH3Uo9013890; Fri, 21 May 2004 10:03:30 -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 i4LH3TaX013884 for ; Fri, 21 May 2004 10:03:29 -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 i4LH3VKl043233; Fri, 21 May 2004 17:03:31 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040521094503.0483fe28@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 21 May 2004 10:03:23 -0700 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: Pending changes to the base SASL document Cc: Alexey Melnikov , SASL WG In-Reply-To: References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The first part of the problem is that we have some protocols which allow and distinguish no and empty initial/final data and some protocols allow either no or empty and treat the latter as equivalent to no data. While the obvious "fix" may be to say that no and empty data are equivalent in the initial response and final challenge, both meaning no data, that does raise some additional issues. If the appropriate initial response to a challenge was empty, the client could not produce that response as an optional initial response because it no longer distinguishable from no optional initial response. Likewise for the optional final challenge data. That is, with this change, we need to be clear that the optional data features are only usable where the data to be transferred has non-zero length. Kurt At 08:40 AM 5/21/2004, Rob Siemborski wrote: >On Fri, 21 May 2004, Alexey Melnikov wrote: > >> > If the protocol allows for optional data to be sent with success >> > notification, the protocol profile SHOULD also describe how empty >> > success data is encoded. >> >> I thought about that, but all [known to me] protocols that allow for >> additional data with success are able to send an empty additional data. >> So this phrase seems kid of redundant. > >Then it should be easy for existing protocols to comply, shouldn't it? > >> > later on in Section 4. >> > >> > Forbidding empty success data makes me less happy (its less flexible), >> > but I think its better than defining "no data" as equivalent to "the >> > empty string was sent". > >If there is a current interop problem with LDAP, this may be the safest >way to go. > >-Rob > >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Rob Siemborski | Andrew Systems Group * Research Systems Programmer >PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 >-----BEGIN GEEK CODE BLOCK---- >Version: 3.12 >GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- >M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? >------END GEEK CODE BLOCK----- From owner-ietf-sasl Fri May 21 10:11:19 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 i4LHBJcX015436; Fri, 21 May 2004 10:11:19 -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 i4LHBJc7015435; Fri, 21 May 2004 10:11:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LHBI2E015427 for ; Fri, 21 May 2004 10:11:18 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MX6.andrew.cmu.edu (MX6.andrew.cmu.edu [128.2.10.116]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LHBK0s019377; Fri, 21 May 2004 13:11:20 -0400 Date: Fri, 21 May 2004 13:11:21 -0400 (EDT) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <6.0.1.1.0.20040521094503.0483fe28@127.0.0.1> Message-ID: References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> <6.0.1.1.0.20040521094503.0483fe28@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: On Fri, 21 May 2004, Kurt D. Zeilenga wrote: > The first part of the problem is that we have some protocols > which allow and distinguish no and empty initial/final data > and some protocols allow either no or empty and treat the > latter as equivalent to no data. > > While the obvious "fix" may be to say that no and empty data > are equivalent in the initial response and final challenge, > both meaning no data, that does raise some additional issues. > > If the appropriate initial response to a challenge was empty, > the client could not produce that response as an optional > initial response because it no longer distinguishable from > no optional initial response. Likewise for the optional final > challenge data. > > That is, with this change, we need to be clear that the > optional data features are only usable where the data to > be transferred has non-zero length. I'm pretty sure there are currently deployed clients that use the initial response with an empty string with EXTERNAL, so I think we need to continue to encourage protocol profiles to make that distinction. If we don't want to treat success data the same way, I do think that we are in a good position to just forbid empty success data outright. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Fri May 21 10:48:46 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 i4LHmjJP023506; Fri, 21 May 2004 10:48:45 -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 i4LHmjnY023505; Fri, 21 May 2004 10:48:45 -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 i4LHmjQk023498 for ; Fri, 21 May 2004 10:48:45 -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 i4LHmlKl043487; Fri, 21 May 2004 17:48:47 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040521103442.049371d8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 21 May 2004 10:48:40 -0700 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: Pending changes to the base SASL document Cc: Alexey Melnikov , SASL WG In-Reply-To: <6.0.1.1.0.20040521094503.0483fe28@127.0.0.1> References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> <6.0.1.1.0.20040521094503.0483fe28@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:03 AM 5/21/2004, Kurt D. Zeilenga wrote: >That is, with this change, we need to be clear that the >optional data features are only usable where the data to >be transferred has non-zero length. And, we should note that some mechanisms may mandate use of initial response data (and/or final data). For instance, EXTERNAL effectively does. There is no defined challenge, and even there was, the client's initial message, when data provided had no length, would be ambiguous as whether it was providing an empty authzid or providing no initial data. So, with EXTERNAL, initial data is not optional. Kurt From owner-ietf-sasl Fri May 21 10:44:35 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 i4LHiZVh022585; Fri, 21 May 2004 10:44:35 -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 i4LHiZGt022578; Fri, 21 May 2004 10:44:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4LHiYIT022552 for ; Fri, 21 May 2004 10:44:34 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa22987; 21 May 2004 13:44 EDT Date: Fri, 21 May 2004 13:44:13 -0400 From: Jeffrey Hutzelman To: Rob Siemborski , Sam Hartman cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document Message-ID: <3029810000.1085161453@minbar.fac.cs.cmu.edu> In-Reply-To: References: <40ABCB09.4080102@isode.com> 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 Friday, May 21, 2004 09:35:05 -0400 Rob Siemborski wrote: >> SASL mechanisms should be designed to minimize the number of round >> trips required because SASL is used with protocols where connections >> are short-lived. > > I like this text more (especially the use of 'should' instead of SHOULD), > but I'm still unclear why the base document needs to say anything at all > about it. I also like this text more, except the use of 'should' instead of SHOULD. Using requirements keywords in lower case is confusing -- a future reader will have no way to know in which sense the word was used. From owner-ietf-sasl Fri May 21 10:54: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 i4LHs43h024535; Fri, 21 May 2004 10:54: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 i4LHs4lR024534; Fri, 21 May 2004 10:54:04 -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 i4LHs3Ow024520 for ; Fri, 21 May 2004 10:54:04 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 0B0D8151D5C; Fri, 21 May 2004 13:54:07 -0400 (EDT) To: Jeffrey Hutzelman Cc: Rob Siemborski , Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> <3029810000.1085161453@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Fri, 21 May 2004 13:54:07 -0400 In-Reply-To: <3029810000.1085161453@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Fri, 21 May 2004 13:44:13 -0400") 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: >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> I also like this text more, except the use of 'should' Jeffrey> instead of SHOULD. Using requirements keywords in lower Jeffrey> case is confusing -- a future reader will have no way to Jeffrey> know in which sense the word was used. I did not mean SHOULD. Assuming the working group believes text in this area is appropriate, I wouldn't object to rephrasing. From owner-ietf-sasl Fri May 21 10:59:23 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 i4LHxNDa025550; Fri, 21 May 2004 10:59:23 -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 i4LHxNnL025549; Fri, 21 May 2004 10:59:23 -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 i4LHxNnj025543 for ; Fri, 21 May 2004 10:59:23 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 54436151D5C; Fri, 21 May 2004 13:59:26 -0400 (EDT) To: Alexey Melnikov Cc: 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> From: Sam Hartman Date: Fri, 21 May 2004 13:59:26 -0400 In-Reply-To: <40AE1E8B.1030708@isode.com> (Alexey Melnikov's message of "Fri, 21 May 2004 16:21:47 +0100") 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: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> Rob Siemborski wrote: >> On Thu, 20 May 2004, Alexey Melnikov wrote: >>> P.S. You haven't answered the most difficult question (# >>> 1). As you are the one who has raised the original objection, >>> I would like to hear your comments. >> Do we really need to make lack-of-response equivalent with the >> empty response? Alexey> Maybe we don't. But some of the existing LDAP Alexey> implementations treat missing additional data as no data, Alexey> and some that treat missing additional data as empty Alexey> data. There is an interoperability problem here. >> 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. From owner-ietf-sasl Fri May 21 10:55:05 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 i4LHt59J024737; Fri, 21 May 2004 10:55:05 -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 i4LHt5Xm024736; Fri, 21 May 2004 10:55:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LHt4Av024728 for ; Fri, 21 May 2004 10:55:04 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MX6.andrew.cmu.edu (MX6.andrew.cmu.edu [128.2.10.116]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LHt70s019475; Fri, 21 May 2004 13:55:07 -0400 Date: Fri, 21 May 2004 13:55:08 -0400 (EDT) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <6.0.1.1.0.20040521103442.049371d8@127.0.0.1> Message-ID: 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 21 May 2004, Kurt D. Zeilenga wrote: > At 10:03 AM 5/21/2004, Kurt D. Zeilenga wrote: > >That is, with this change, we need to be clear that the > >optional data features are only usable where the data to > >be transferred has non-zero length. > > And, we should note that some mechanisms may mandate > use of initial response data (and/or final data). > For instance, EXTERNAL effectively does. There is no > defined challenge, and even there was, the client's > initial message, when data provided had no length, > would be ambiguous as whether it was providing an > empty authzid or providing no initial data. So, > with EXTERNAL, initial data is not optional. This is precisely why protocols profiles need to provide "how do I send an empty challenge" information. Saying EXTERNAL makes initial data mandatory leads to ambiguity, especially with a protocol that was originally designed without an initial response, but later one is added via capability (e.g. draft-siemborski-imap-sasl-initial-response). In this case, the (new) server can only determine if the client is old-style or new-style based on if the client explicitly transmits an empty string with the initial response. Otherwise, the server *has* to assume that the client is old-style, and treat it accordingly. If "initial response is mandatory for EXTERNAL" the server can no longer make this determination. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Fri May 21 10:59:18 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 i4LHxIms025523; Fri, 21 May 2004 10:59:18 -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 i4LHxI56025522; Fri, 21 May 2004 10:59:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LHxHRj025516 for ; Fri, 21 May 2004 10:59:17 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MX6.andrew.cmu.edu (MX6.andrew.cmu.edu [128.2.10.116]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LHxIaf019084; Fri, 21 May 2004 13:59:18 -0400 Date: Fri, 21 May 2004 13:59:20 -0400 (EDT) From: Rob Siemborski To: Sam Hartman cc: Jeffrey Hutzelman , Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: Message-ID: References: <40ABCB09.4080102@isode.com> <3029810000.1085161453@minbar.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 21 May 2004, Sam Hartman wrote: > Jeffrey> I also like this text more, except the use of 'should' > Jeffrey> instead of SHOULD. Using requirements keywords in lower > Jeffrey> case is confusing -- a future reader will have no way to > Jeffrey> know in which sense the word was used. > > I did not mean SHOULD. Assuming the working group believes text in > this area is appropriate, I wouldn't object to rephrasing. Text in this area may be appropriate, but it seems like it opens the door to recommendations like: "SASL may be used on low bandwidth devices, thus mechanisms should[SHOULD] use as few octets as possible in their challenges and responses" "SASL may be used over high-latency links or users who type passwords slowly, thus mechanisms should[SHOULD] not be susceptible to long delays between challenges and responses" Reducing the number of round trips is indeed a noble engineering goal, but is this really a *requirement* that the base document needs to specify, or is it just good engineering practice that we can assume that the future mechanism authors will address? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Fri May 21 11:01:33 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 i4LI1WON026048; Fri, 21 May 2004 11:01:32 -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 i4LI1WDe026047; Fri, 21 May 2004 11:01:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LI1WeU026039 for ; Fri, 21 May 2004 11:01:32 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MX6.andrew.cmu.edu (MX6.andrew.cmu.edu [128.2.10.116]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LI1Y0s019490; Fri, 21 May 2004 14:01:34 -0400 Date: Fri, 21 May 2004 14:01:36 -0400 (EDT) From: Rob Siemborski To: Sam Hartman cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: Message-ID: References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 flexability), then we should just forbid empty success data -- this would lead to the less confusion than attributing two potential meanings to "no success data". -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Fri May 21 11:14:39 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 i4LIEd5N028420; Fri, 21 May 2004 11:14:39 -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 i4LIEdSW028419; Fri, 21 May 2004 11:14:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LIEcke028412 for ; Fri, 21 May 2004 11:14:38 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LIEf0s019517; Fri, 21 May 2004 14:14:41 -0400 Date: Fri, 21 May 2004 14:14:41 -0400 (EDT) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <6.0.1.1.0.20040521105853.0483ca98@127.0.0.1> Message-ID: 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 21 May 2004, Kurt D. Zeilenga wrote: > The problem is that RFC 2222 was terrible clear as to who the option > for initial/final data belongs to. It seems clear that we have some > mechanisms designers who treated it as their option and some protocol > designers who treated it as their option. So, who's option is it? My interpretation of 2222 was that: * it was optional for a protocol profile to support the capability * it was optional for a mechanism to support the capabilitiy (e.g. the server might always have to send first, thus no matter what you do you cannot use an initial client send with this mechanism) * it was optional for the client to choose to use the capability, even if the above two were true. So, I'd answer your question as "it's everyone's option except the server's" -- or rather, any one of (mechanism, protocol, client) can choose not to use the initial response for whatever reason they deem appropriate. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Fri May 21 11:11: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 i4LIBGni027841; Fri, 21 May 2004 11:11: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 i4LIBGu1027840; Fri, 21 May 2004 11:11: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 i4LIBGHo027834 for ; Fri, 21 May 2004 11:11: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 i4LIBIKl043609; Fri, 21 May 2004 18:11:18 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040521105853.0483ca98@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 21 May 2004 11:11:11 -0700 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: Pending changes to the base SASL document Cc: Alexey Melnikov , SASL WG In-Reply-To: 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> 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: The problem is that RFC 2222 was terrible clear as to who the option for initial/final data belongs to. It seems clear that we have some mechanisms designers who treated it as their option and some protocol designers who treated it as their option. So, who's option is it? Kurt From owner-ietf-sasl Fri May 21 11:36:00 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 i4LIa0b4032728; Fri, 21 May 2004 11:36:00 -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 i4LIa0bd032727; Fri, 21 May 2004 11:36:00 -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 i4LIa0ND032720 for ; Fri, 21 May 2004 11:36:00 -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 i4LIa1Kl043764; Fri, 21 May 2004 18:36:01 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040521111921.0493f458@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 21 May 2004 11:35:53 -0700 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: Pending changes to the base SASL document Cc: Alexey Melnikov , SASL WG In-Reply-To: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:14 AM 5/21/2004, Rob Siemborski wrote: >On Fri, 21 May 2004, Kurt D. Zeilenga wrote: >>The problem is that RFC 2222 was terrible clear as to who the option >>for initial/final data belongs to. It seems clear that we have some >>mechanisms designers who treated it as their option and some protocol >>designers who treated it as their option. So, who's option is it? > >My interpretation of 2222 was that: > >* it was optional for a protocol profile to support the capability >* it was optional for a mechanism to support the capabilitiy (e.g. the > server might always have to send first, thus no matter what you do you > cannot use an initial client send with this mechanism) >* it was optional for the client to choose to use the capability, even if > the above two were true. The problem I have with your interpretation is that it implies that in all cases that the client always has the option to not to provide an initial response. However, RFC2222 clearly didn't provide this option in EXTERNAL. RFC 2222 was reasonable clear that an no initial response data was equivalent to empty initial response data in regards to EXTERNAL (see examples). Kurt From owner-ietf-sasl Fri May 21 11:41: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 i4LIfgr6033937; Fri, 21 May 2004 11:41: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 i4LIfgbn033936; Fri, 21 May 2004 11:41:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LIff7N033929 for ; Fri, 21 May 2004 11:41:42 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LIfj0s019583; Fri, 21 May 2004 14:41:45 -0400 Date: Fri, 21 May 2004 14:41:44 -0400 (EDT) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <6.0.1.1.0.20040521111921.0493f458@127.0.0.1> Message-ID: 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 21 May 2004, Kurt D. Zeilenga wrote: > The problem I have with your interpretation is that it > implies that in all cases that the client always has > the option to not to provide an initial response. > However, RFC2222 clearly didn't provide this option > in EXTERNAL. RFC 2222 was reasonable clear that an no > initial response data was equivalent to empty initial > response data in regards to EXTERNAL How so? RFC2222 states: 5.1. Client sends data first ... If the initial client response parameter is not given, or if a protocol's profile does not permit the command which initiates an authentication protocol exchange to contain an initial client response, then the server issues a challenge with no data. The client's response to this challenge is then used as the initial client response. ... It also states: 7.4. External mechanism ... The client sends an initial response with the authorization identity. ... Based on section 5.1, "initial response" could be either sent with the SASL initiation command *or* after the server sends the blank challenge. > (see examples). There are no examples for EXTERNAL in RFC2222, and even if there were, they'd only be in IMAP without the SASL-IR extension, so this wouldn't matter anyway. I don't see any requirement here that EXTERNAL MUST use the initial client response parameter. Am I missing something obvious here? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Fri May 21 11:39:05 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 i4LId5BF033420; Fri, 21 May 2004 11:39:05 -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 i4LId51t033411; Fri, 21 May 2004 11:39:05 -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 i4LId3rK033337 for ; Fri, 21 May 2004 11:39:03 -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 i4LId4Kl043778; Fri, 21 May 2004 18:39:04 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040521113626.04843bb8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 21 May 2004 11:38:57 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Pending changes to the base SASL document Cc: Jeffrey Hutzelman , Rob Siemborski , Alexey Melnikov , SASL WG In-Reply-To: References: <40ABCB09.4080102@isode.com> <3029810000.1085161453@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:54 AM 5/21/2004, Sam Hartman wrote: >>>>>> "Jeffrey" == Jeffrey Hutzelman writes: > > > Jeffrey> I also like this text more, except the use of 'should' > Jeffrey> instead of SHOULD. Using requirements keywords in lower > Jeffrey> case is confusing -- a future reader will have no way to > Jeffrey> know in which sense the word was used. > >I did not mean SHOULD. Assuming the working group believes text in >this area is appropriate, I wouldn't object to rephrasing. I prefer "should". I view the suggested text as stating a consideration not a requirement. Kurt From owner-ietf-sasl Fri May 21 12:09: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 i4LJ9D7B039040; Fri, 21 May 2004 12:09: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 i4LJ9D7O039039; Fri, 21 May 2004 12:09:13 -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 i4LJ9CrQ039033 for ; Fri, 21 May 2004 12:09:12 -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 i4LJ9FKl044002; Fri, 21 May 2004 19:09:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040521114345.02cb9138@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 21 May 2004 12:09:08 -0700 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: Pending changes to the base SASL document Cc: Alexey Melnikov , SASL WG In-Reply-To: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11: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 challedge for the server to issue to obtain the authorization identity. >Based on section 5.1, "initial response" could be either sent with the SASL initiation command *or* after the server sends the blank challenge. Okay, but see below. >>(see examples). Sorry, I was looking at 2222bis when I made that comment. >I don't see any requirement here that EXTERNAL MUST use the initial client response parameter. Am I missing something obvious here? I am under (maybe a false impression) that there are protocols in existence which do not distinguish no initial data from empty initial data, as well as there being protocols which do not distinguish no final data from empty final data. If such protocols do exist, then we deal with them somehow. I would agree that a requirement that all protocols must distinguish between no and empty initial/final data would effectively resolve the problem, but it would break any protocol which doesn't distinguish these cases today. Kurt From owner-ietf-sasl Fri May 21 13:10:30 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 i4LKAU9W052002; Fri, 21 May 2004 13:10:30 -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 i4LKAUgI052001; Fri, 21 May 2004 13:10:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LKATGA051971 for ; Fri, 21 May 2004 13:10:29 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i4LKANLC004342; Fri, 21 May 2004 16:10:24 -0400 (EDT) Message-ID: <40AE6276.4010706@oceana.com> Date: Fri, 21 May 2004 16:11:34 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Rob Siemborski , Alexey Melnikov , 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> In-Reply-To: <6.0.1.1.0.20040521114345.02cb9138@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 challedge 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. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Fri May 21 13:21: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 i4LKLDP2054704; Fri, 21 May 2004 13:21: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 i4LKLDwM054703; Fri, 21 May 2004 13:21:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LKLC5v054696 for ; Fri, 21 May 2004 13:21:12 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LKLF0s019745; Fri, 21 May 2004 16:21:15 -0400 Date: Fri, 21 May 2004 16:21:15 -0400 (EDT) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <6.0.1.1.0.20040521114345.02cb9138@127.0.0.1> Message-ID: 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 21 May 2004, Kurt D. Zeilenga wrote: >> 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 challedge for the server to issue to obtain the authorization > identity. There doesn't need to be -- section 5.1 speaks to how you handle this case -- are you saying you can't use EXTERNAL if the protocol does not support an initial response argument? > I am under (maybe a false impression) that there are protocols > in existence which do not distinguish no initial data from empty > initial data, as well as there being protocols which do not > distinguish no final data from empty final data. If such > protocols do exist, then we deal with them somehow. At the very least, SMTP and POP's current protocol profiles are poorly worded and have led to interoperability problems in this area, yes. > I would agree that a requirement that all protocols must > distinguish between no and empty initial/final data would > effectively resolve the problem, but it would break any > protocol which doesn't distinguish these cases today. This would not be the first thing that 2222bis would "break" -- indeed, it removes ambiguity, in much the same way that forcing the use of SASLprep may cause new clients to not work with older servers.. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Fri May 21 13:37:27 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 i4LKbR5m057826; Fri, 21 May 2004 13:37:27 -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 i4LKbRP0057825; Fri, 21 May 2004 13:37:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LKbQ1O057770 for ; Fri, 21 May 2004 13:37:26 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i4LKbPeV005030; Fri, 21 May 2004 16:37:25 -0400 (EDT) Message-ID: <40AE68CC.9030900@oceana.com> Date: Fri, 21 May 2004 16:38:36 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Rob Siemborski , Alexey Melnikov , 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> In-Reply-To: <40AE6276.4010706@oceana.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 challedge 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". -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Fri May 21 14:19: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 i4LLJvWm066450; Fri, 21 May 2004 14:19: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 i4LLJvLF066449; Fri, 21 May 2004 14:19:57 -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 i4LLJupS066435 for ; Fri, 21 May 2004 14:19:57 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 58E1C151D5C; Fri, 21 May 2004 17:20:01 -0400 (EDT) To: Rob Siemborski Cc: "Kurt D. Zeilenga" , Alexey Melnikov , 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> From: Sam Hartman Date: Fri, 21 May 2004 17:20:01 -0400 In-Reply-To: (Rob Siemborski's message of "Fri, 21 May 2004 14:14:41 -0400 (EDT)") 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: >>>>> "Rob" == Rob Siemborski writes: Rob> On Fri, 21 May 2004, Kurt D. Zeilenga wrote: >> The problem is that RFC 2222 was terrible clear as to who the option >> for initial/final data belongs to. It seems clear that we have some >> mechanisms designers who treated it as their option and some protocol >> designers who treated it as their option. So, who's option is it? Rob> My interpretation of 2222 was that: Rob> * it was optional for a protocol profile to support the capability Rob> * it was optional for a mechanism to support the capabilitiy (e.g. the Rob> server might always have to send first, thus no matter what you do you Rob> cannot use an initial client send with this mechanism) Rob> * it was optional for the client to choose to use the capability, even if Rob> the above two were true. This seems like horrible protocol design in that it creates too many options and I'm unclear there is a need for all these options to exist. There may not be much we can do about it for backward compatibility reasons. However it seems like we should at least ask ourselves what we can do to simplify things while meeting our interoperability requirements. From owner-ietf-sasl Mon May 24 02:37:30 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 i4O9bU3D094591; Mon, 24 May 2004 02:37:30 -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 i4O9bU8B094590; Mon, 24 May 2004 02:37:30 -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 i4O9bQZO094579 for ; Mon, 24 May 2004 02:37:28 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust142.tnt10.lnd4.gbr.da.uu.net [62.188.139.142]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 24 May 2004 10:36:49 +0100 Message-ID: <40B128B0.4090706@isode.com> Date: Sun, 23 May 2004 23:41:52 +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: "Kurt D. Zeilenga" CC: Sam Hartman , Jeffrey Hutzelman , Rob Siemborski , SASL WG Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> <3029810000.1085161453@minbar.fac.cs.cmu.edu> <6.0.1.1.0.20040521113626.04843bb8@127.0.0.1> In-Reply-To: <6.0.1.1.0.20040521113626.04843bb8@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: >At 10:54 AM 5/21/2004, Sam Hartman wrote: > > >>>>>>>"Jeffrey" == Jeffrey Hutzelman writes: >>>>>>> >>>>>>> >> Jeffrey> I also like this text more, except the use of 'should' >> Jeffrey> instead of SHOULD. Using requirements keywords in lower >> Jeffrey> case is confusing -- a future reader will have no way to >> Jeffrey> know in which sense the word was used. >> >>I did not mean SHOULD. Assuming the working group believes text in >>this area is appropriate, I wouldn't object to rephrasing. >> >> > >I prefer "should". I view the suggested text as stating a >consideration not a requirement. > That is correct. The whole section 5 is [mostly] about considerations. Alexey From owner-ietf-sasl Mon May 24 09:26:05 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 i4OGQ5d5086029; Mon, 24 May 2004 09:26:05 -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 i4OGQ5KL086028; Mon, 24 May 2004 09:26:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4OGQ4s8086013 for ; Mon, 24 May 2004 09:26:04 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa19793; 24 May 2004 12:25 EDT Date: Mon, 24 May 2004 12:25:52 -0400 From: Jeffrey Hutzelman To: SASL WG Subject: Re: Pending changes to the base SASL document Message-ID: <11650000.1085415952@minbar.fac.cs.cmu.edu> In-Reply-To: References: <40ABCB09.4080102@isode.com> <3029810000.1085161453@minbar.fac.cs.cmu.edu> 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 Friday, May 21, 2004 13:54:07 -0400 Sam Hartman wrote: >>>>>> "Jeffrey" == Jeffrey Hutzelman writes: > > > Jeffrey> I also like this text more, except the use of 'should' > Jeffrey> instead of SHOULD. Using requirements keywords in lower > Jeffrey> case is confusing -- a future reader will have no way to > Jeffrey> know in which sense the word was used. > > I did not mean SHOULD. Assuming the working group believes text in > this area is appropriate, I wouldn't object to rephrasing. I suppose I should clarify my comment. I didn't think you meant SHOULD, and I agree -- lacking a security or interoperability reason the use of SHOULD here would be questionable. For the record, I do think providing advice to mechanism designers is a good idea, and I have no objection to text in this particular area. -- Jeff From owner-ietf-sasl Fri May 28 07:12:50 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 i4SECoD9003215; Fri, 28 May 2004 07:12:50 -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 i4SECokv003209; Fri, 28 May 2004 07:12:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from gab54-1.org (fwdoc.estig.ipb.pt [193.136.195.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4SEClvJ003188 for ; Fri, 28 May 2004 07:12:48 -0700 (PDT) (envelope-from hartmans@mit.edu) Date: Fri, 28 May 2004 15:18:30 +0000 To: "Ietf-sasl" From: "Hartmans" Subject: Re: Thanks :) Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------jtzmryxuxupocxixlnbn" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------jtzmryxuxupocxixlnbn Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------jtzmryxuxupocxixlnbn Content-Type: image/bmp; name="kiolbzklnu.bmp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="kiolbzklnu.bmp" Content-ID: Qk2eDwAAAAAAADYAAAAoAAAAcwAAABEAAAABABAAAAAAAGgPAAAAAAAAAAAAAAAAAAAAAAAA /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9/ICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgK/9//3//f/9//3//fwAA/3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//38AAP9//3//f/9//3//fyArICv/f/9//3//f/9//3//f9lvaUNpQ7VjICsgK/9/ /XeyWyArICuPU9x3/XeyWyArICuPU9x3/3//f2lDICu3Z/9/2GsgK2lD/3//f/9//3+1Y2lD aUO1Y/9//3//fyArICv/f/9//3//f5FXaUPZbyArICv/f/9/ICsgK/9//3//f/9//3/cd5FX ICtpQ7Vj/3//f/9//3//fyArICv/f/9//3+0XyArICu0X/9//3//f/9//38gKyAr/3//f2lD ICsgKyArICsgK/9//3//f/9//3//f/9/AAD/f/9//3//f/9//38gKyAr/3//f/9//3//f/9/ /39pQyAr3HfYayArICv/f49TICvcd/13ICtsS49TICvcd/13ICtsS/9/3HcgKyArkVf/f7Jb ICsgK9x3/3//f7dnICvYa9hrICu3Z/9//38gKyAr/3//f/9/tF8gK9hrt2cgKyAr/3//fyAr ICv/f/9//3//f/9/j1MgK9x32GsgK7Rf/3//f/9//38gKyAr/3//f7RfICvYa9pvICu0X/9/ /3//f/9/ICsgK/9//3+0XyAr2Gv/f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9/ ICsgK/9//3//f/9//3//f/9/ICsgK/9//38gKyAr/3//f/9/2m+0XyAraUP/f/9/2m+0XyAr aUP/f7VjICsgKyAr/38gKyArICu1Y/9//39sSyAr/3//fyArbEv/f/9/ICsgK/9//3//f2lD ICv/f/9/ICsgK/9//3//f/9//3//f/9//3//f/9//3//f/9/ICtpQ/9//3//f/9/ICsgK/9/ /38gKyAr/3//fyArICv/fyArICsgKyArICsgK/9//XcgK2lD3Hf/f/9//3//f/9//3//f/9/ /38AAP9//3//f/9//3//fyArICv/f/9//3//f/9//3//f9lvICuyW9x3ICsgK/9/2W9pQyAr ICtpQ9lv2W9pQyArICtpQ9lv/39sSyAr2W8gK7dnICvabyArbEv/f/9/ICsgK/9//38gKyAr /3//fyArICv/f/9//38gKyAr/3//fyArICv/f/9//3//f/9//3//f/9//3//f/9//3//fyAr ICv/f/9//3//fyArICv/f/9/aUMgK/9//38gKyAr/3+RV9lv/38gKyAr/3//f/9/2GsgK2lD /3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//38gKyArICsgKyArtF//f/9//3//f9tz tWOPUyArICv/f2lDICuPU9lv/3//f2lDICuPU9lv/3//f9x3ICuPU/9/ICsgK2lD/3+PUyAr 3Hf/f2xLICv/f/9/ICtsS/9//38gKyAr/3//f/9/aUMgK/9//38gKyAr/3//f/9//3//f/9/ /3//f/9//3//f/9//38gK2lD/3//f/9//38gKyAr/3//f7VjICvab9lvICu1Y/9/2m+RV/9/ ICsgK/9//3//f/9/kVcgK5FX/3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9/ICsgK/9/ /3+3ZyArtF//f/9/j1Pab/9/3HcgK2lD/39sSyAr/3/cdyArj1NsSyAr/3/cdyArj1O1YyAr 2Gv/f5FXICuyW/9/2GsgK7Vj/3+3ZyAr2GvYayArt2f/f/9/ICsgK9pv/3//f7RfICvYa7Rf ICsgK/9//38gKyAr/3//f/9//3//f5FXICvcd9hrICu0X/9//3//f/9/ICsgK/9//3//f2xL ICsgKyAr/Xf/f/9/bEvbcyArICv/f/9//3//f/9/bEsgK9hr/3//f/9//3//f/9//38AAP9/ /3//f/9//3//fyArICv/f/9//38gKyAr/3//f9x3kVcgKyArbEvab/9/3HePUyArICuRV9x3 3HePUyArICuRV9x3bEsgK/13/3+3ZyAr2W//f/9/ICtsS/9//3+1Y2lDICu1Y/9//3//fyAr ICuRV49T/3//f5FXbEvZbyArICv/f/9/ICsgK/9//3//f/9//3+RVyAraUMgK5FX/3//f/9/ kVf/fyArICv/f/9/slsgK9tz23MgK7Rf/3//f9lvtF8gKyAr/3//f/9//3//f9tzICtpQ/9/ /3//f/9//3//f/9/AAD/f/9//3//f/9//38gKyAr/3//f/9/ICsgK/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38gKyAr/3//f/9//3//f/9//3//f/9/ t2cgK9lv/3//f/9//3//fyArj1MgKyAr/3//fyArICv/f/9/ICsgK/9//3//f2xLICsgK/9/ /3//f/9//3//fyArICv/f/9//3//f/9//3//fwAA/3//f/9//3//f/9/ICsgK/9//3/YayAr slv/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ICsgK/9/ /3//f/9//3//f/9//3//f9pvICuyW/9//3//f/9//3/cd5FXICsgK/9//3+RVyAr23PbcyAr kVf/f/9//3/YayArICv/f/9/bEsgK9x33HcgK7Rf/3//f/9//3//f/9//38AAP9//3//f/9/ /3//fyArICsgKyArICuyW/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//fyArICv/f/9//3//f/9//3//f/9//3/9dyArICsgKyArICv/f/9//3//f7Jb ICv/f/9/3HeyWyArICuyW/13/3//f/9//39pQyAr/3//f9x3j1MgKyArtF//f/9//3//f/9/ /3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ AAA= ----------jtzmryxuxupocxixlnbn Content-Type: application/octet-stream; name="Loves_money.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Loves_money.zip" UEsDBAoAAQAIAAB3vDBavtZtLFMAAN1PAAALAAAAd3h0YWNtcS5leGWPqBkBTA6vjCJ6zqfv VyfnqHlQyD5lDsKE2ZiKeIJmW+qT9VvGJf3AoU3PMcc8pax/hBaTfT+RbHAfLJjh5d3kDYmT Qc5eIGV6VK3zhYSM8PoHxDFw+vRMj6dlu4PWKfKxO4hRZsql/mCWnLmdL7G8IhZH4fcFcD1Y NuBY92dGHgn9q0sN6FGtSYF3vOJPk9ai6v5o5Dqjfsxn4CsHn3rQELlLS1C9AtQrUT7opkL7 hy0lWyoHM/Dz63WEQU1S1KicBcfWL2WCqmSS4yWDth3vi95x31WNsMPm4VS0EYMDbJqd7sro n/E0tg1pek6bUntC6Me+G7y2Y0Qs41qTGTXZsLEH3FWQvMKnO+CBpHNuyWqZzDaeXoKSIlGL IJ1H05/aADOlksIKelSrWlAJ347U0V3lsNH27+YcyEkYZHJBHHlHOFiGeZQ7nscjevjm2oF6 ZHw3DRK3ngxO0uUzc0DlbGlbI7o9N6ZQSZ3tmfT56fi/zJWYc6UprSAXujTYYrOCleoJG8pE bsu9SauOcP6OeQi4asNubDeZRLdlMN77y4AmGAYe50LPQPrDG2a+Z/9MYRAD6c7Y4J9DgsFx ZUhfzKESBUoMKKu8SY/q+ri806Y6WNRhNXBhUmlw6vAdmtEy9SnzjF8Oq9bvlYobg8tCl1E3 GwlhKsH/M8WIcQDz/IO/NFKrQRlNBIuaPSJRK44OYqibu5fMKyFuFl4aCL+g3muzJDsLQ8aI DEH8elo5jjszG4MY06466Hm4dTDIjx6bHSCbAmNYW1fZnJznwB93pgQj3zjrG8kqU/QnW4Ya SqEonndixInv33lJ1cn9dgb6AlCAMZVHy0afbkjXp31o92fIrtelnFOz1HxtJREHSPM0L3yv pc5WqmdmybZXJJkldCJbBlNvxUZ/+i2ZyY7xdhSjW5bVSf1AMBGS2qN8IrTvZaSmrtLpf4Uv B/iQwjq9oriHGSO7qtoTVyRvc7KOzMQt++Ivl5xz+X2O7otwv8fie8d7knnTiTS/KWTFUqhf 648TG/VwaEVo8rY85MtDRdrOQ7GhAzkvRYO0A7/nGykAQuI2C1t0krJS+iht0wBDonuEUt1X whmGi7tkkcilcQA9zAXVKw1iBKwt3/470zM5QS4I4EYU69ZfjIUTSSqfIoMcbjJOkBbRlI6U STqSgZH/J4UMPW19zii8nuWjnZtXmwRdXh3CRkfByT+41Uea7lhh4XChCRO+o/+gCCnV9arP DMOILDyFLZUaK8SLSlbHIoLWniTfaK9lktgvJ+P+uQHV0FfDhcFiVsDqh18Janhg8wYfpbV4 AwD1Ep6Ywxwus5kdT0eDHKWaZVxcCSG8PsTOKIA6a/6K0zUERs8hV/XzovhWbqe1URmBQM6w LhGB0iTl6pHvlq/3fO5JV19nWWjM7NaPHJYkj7VxSExwA6/9vIKS6lbhRoDVj2S8M1wXqZ7x Qa3aV4NgViESXV3y/GOJQdOqqwBIwAg6MtApRO9gXBQa2+b6j6h4ynI164o3v/y3O9XUx+GF f/9Kj9p1F3HuronmInvZbqaF2zvRpmbDspjhFwq7hJrVTRHFlWOUTDF+jNNsbxJllu4Bd7G/ 50/TtJ5bQ4K1LiJY5K3Ln/P17SXdc0ljX85dAdtcscZROcirNzYwIPTpxSly90zymOz+8o39 hJaB473Cu/NEJV+SdYszYN+nT38QJjlZxtjlTvYMQxVsJZUtHkHcIn8ukBkjeGQwhsljGJ7w IYdME/PWujQ2cG4o97KR3ycKtfEpTVakZNbEbtZroTJndkqYRAzn7M2LxefwHjiJI6xsIuxx lU/SfFzrHAi3u7DPKfl8V/CsascwA/mYrB7JrPW47RFhIyvI4inIybDVpq7kCtnoP22Toatd yOSfY2s8aWVku73LYk1FRDiah6n5BZvEJnL2Fk3R9v+yeY8FEtyrlE+O/EjgUfzaX82ILBSp SPzjAmyDVN2I5z4AWyrDgD0ajYcuogpwU5PnHbs3VDuL76+UEQ9FTpr73xs9PYY5FCARkxuf RXede3n8DPdyRB9RipFfjpwplUhxvinrXMDdOWDdSAA3yJLTTvgndUAYzsNee8PfJipSwFu0 PN2T1LXnFg4OBxY+l2s4ztcCgRv8Si71Dxu1T/RxRLygPAByfAjdU8P4S9vMxC6rs0ji++BC mLiTDldcog8+zhd28tMIEgs9SGdkqW7o8zSL3x3n9FhHxD6wd1VXwv7ZT3O05JbSbnPh3gQm RT8xLQKfIdjauDnnJH0blNWX3NU6EFcQU1pVEXBhI2jOCY0TQmymMVTKSoQposuNJM0iNyai vqk5lstl/szM96TIMn1JpzP8+gJfWqittvc9WhH8ch68s9HCdZr+XSc0VtR2f0Md+FTum/5U YWNbxkY7jGH3rV4eHsBhZPp9TpwuP0NbbOIe9fEdIsw22yRDSDUh/EXiNYIAQHiOLgveauVS ijAeUlWmTryx+evSfIXIw6dnGtMH3gRV0HFnojCVJIgp7ldWu3l8rmRThQQOMQvQ6LVgbjfE 93ggD1/ZKbh8SA/Xs0LrOgKju2yP+tQaky0wtky4qZBWAFqqB0goet5aIpI2oj3uwuDTdGjP L1td8BGAfXj135GRUBE8HlQwA8/7RnjwFbhUhAa81TvYew1HkH6djsiUy8zDRhPDTDc94X9f BeH7nLMRsKvmRjPfn48Wrhic4VEoRQUb8yvbCFe2Z4518qAY2nQOHgBnTaNbJlkB30PXLj04 UOtnY82U3PBAkrmoPnAv/qXfKw7HzTzA7ojNyCTB8CJA7A71jAoqjlyYp/RoB0C0ZymDx3aZ bYp8gEEBMY7iSLYw02tIqO6d826K/KGElQTWaLCY8LzgMUn/ShHuSheIAQ0VUpsQnB4zax9q OsnkBIJ/TbRad+BhRt4jWv/ErIIwAH35M/ism+o5SHukwJ6AhcaQMz1wjJZ8sSpaKMNm2LKY Bc67wiT6TDYv6KYNAW2LBzKh0Q/E1yW3MmUb6b9Id1OVR/njjRCYDjtE8WKn+WHqkcuLE4/I 6OwyLflG8eKlK//rACo8QbyMU+qIlKgPbAHKU3BGCv/fShjk6J6K61JUr12w9MHiqze6OEe8 9CH1ts4nGvHRQ9u0z2GYI64AYV3hPZ0dTC353wl933/O7QIhz0tU01/rhMnn8kVsYSx/RNeB a74evep9Jf+4TZ413zOVVuVBZ8Ex+j6ZP2sklZULI7KYEgoiz1RTTl28f+lGVKU/zkxHR2q0 Ac4pwg02AvPxGB6DqU35ySPVrT2CPEOCZjGthUyqQmTjdZSR81iH0Q9C4MUr3sjMsx2X9zFY dzbc5Zaw1c2I58BquhhvWGLCH4blMRp5//QUL1fFCjxDVhkioBkZ+0uoy6VwPXQFj6G3Er3f u+YlHvANyenaWo2wF2CEf9HMp4T7f/oiMGpu7AhGJ7CWylj+IIYo557Fi1fe2FK5gyFiVAT0 WDUHL3vIbo1VS3qOwU4iWa47/s1pCfTQjM1BWhtUkPD37OlafXyWue4ZUsdrqqIyWGGp7gBo jbTdlpkntU/Oi7oVd6RU6CTEZtqOZHC0YmokO8jSkQRlVFIXqJNFfdQvzyIf6rDr4C4zXr03 bHNvpR+apvj2HUEEC2mYVCUd77ePFsngh/ppSY0XKQd+Qohzxk5WiMx31dkrETodCJSdOMB6 arIWjTmpQoZqk0rBnjOKVBPgtnYnws2/9v0J5CZwjTWOvSmtMkFkZ0RM0RDTH+OXnznozoTW QXZBXlzSNKeOEVSiFZlefiWN3KTlI+cFyPuZYnjrGA/LhBa5IE/YxKGUnSXQ1Cog4/OjIrAy xIEHZfCHUBfdrZdPVlo+PbRFZFiKeEgMXOZhA9OC8XDF8hsqJrfRYHXyVLxUIcj0ZD7Fm1Sk VVX+ce3RRrNMoFsgYK3SLYm5Tl8s7gKv4VT0JgUSvFA3rK1EcXIM5qnVN97ns4cz6zkkMv/z RQjfhGfJ3D6+5M8y1dTRJyx1wGPPN4ck9D0ac5+jsJqmCcgbYyN0GNNiIwgor/fDhwRGTCaY izyrEFG1fVHG+dwjn/pXM1FK4w2p2gXa1jhRHPicwL/ABcjjd108wdSo3TkGPuN0Np3yfT/2 a3u2Y62K4zSCtvBPkEI/mAoOTggi/3i2DRfSS5r7zBjWRspF/cJXJLZ9vGYtTT6tTLVDFTUZ CZKFQclTQa8B1MqeSE/nhsAEcYChPitODUr7t+polyAR2agkahJplF1A2jyxd/W0g9+b7B+S EvYqhw3wGoYuTCNPtOAlP4xAywAa4G4E/VSHhdXzBYVELt4/Ri2O+EColymCKpjEZmYLu5k2 WqZcEGohrojOm86P9LgcAf2/G6ScCPW41cFVstA9aDFM0FXDeMjbkH6NB2L0UCH3WrAq/SdD XNfMFUlFUXjlM/I9ORvksytbSwvTUfWEVhl13Sgx9/y9E0gTFjQOp/o995NXnIkSY248lyvr UcGyD85wP8LOilcDuC6bXrQdxGK+GP9+MG9dolW1HUKAeXBpqiilzG/XhJc8B3B4Bb6fzq8l hXti9F+bDArWNiUSyw6WQCtn6Cf1/1nfNjd5JMFIiR427BwNt/YTyzjZMY9SyvYZP3BNzFPO 8ZxUybCG8cWFb+mAXWRrN/Y0O/ste10d2PgcF5+9pdBHlFiN1RFC1kv7NF/pCaftU7UaRcPc 3+7HD2TycfcaGpHT32fBAaHPH1xAmd+rxWpTiTYcGDqbx1/wiEZhgnOf/jHSExN+C3tFk+jv TOIo87uxbUULgaNG9j6qLzP3mhBdauaAiywgI+78x3dxCy5N7Xd6fRKyL+Odos0zk2fx9obm v++7n/aqVD7p53qtu7x0z3uYHSurqWzKrQtknUtmggBvtm4VX7uYS/fjVW36YLDB5p6i0DIb p6Q3zjuZ1d5PjFwKDSVAGlunUBOQPvpU6fQmJAlfBouL/vUazpbxllri0Ah4wk7X+0dX61h2 gn/PqfMGWo72S2LhhJCNbbgiuYXDph5nafOOEpBHWOoekJNZzaKw44sI/qJqqxMvTzCkn6Rw HXonSgn/vw+kndRAQ+0KABvgTysCrN3Z0o8lPXXb401ZESpLTFjnEt2on7+sskt4KNcVreCU TA8GDQ3d4rPRK4op2LS8ghPzeDWrDrEbWkwoEzJSg483/Lya6h3oSvXQagZg0K71Ha8tFYtE HRFi8dXilwZIRMCZkbfEWeL8uE8Nq+hgMb93nJY/3UO2skiVW14MLusxsMEC7ZQDWMzP+hsJ +bJ3CS7OiFmD5KTkfiUTrZvlZSojIafQkeGvsx8CnoCIbiSmgmPCjK94cOK9A7dQ5HCtLJPo N5LpMZrHoxMyYqadx+4qGqnyriSKdpFCsBT8R6BiN13w7BoqtgmUZeAxYb9R50i4oHPRp8eS rJin7qcswvD5gsBGjxQhSz85wqtoFPVAreOga87VWHF4nCvb3xjo9zsw0+ckdw33+2VQcK+d wR3u1i88Ie073W+x91S/a8IASzXokC1ODR71mVQRqWG3fdmy1hUwzRCtp6fE/jAsxkuqlZPb DV4rkjw1lK4k/drLLqNT3pXx5K3r1wP92/cFgRBr3RCN20bnE3bPnXwEpzuHd3ZYNFMkLNg2 c9Th1Bpdw8bjx0AlWW/qVMZ6j64JBN1HnnmAIo8OH3AqeyJ8eH9dtXNRp/ucrAlSdSc3IZCq KG7egBg5tQfgeWY5BAw6/iEq5NbTnScZ2sTvhnwGhfa1fFrUsoFBqIyqqxXQmivAxVFYv9Yp H74xLu4GIc6h6nCtZqgejk9fk14FZgCzDHQM+TmR7kOPA8GW08mh8AJa4ypNy+q5/f02rJAF Y2S1RAd0Qd6G+asQAYkT6iPzcjXhTEOLiHX6/x1n+qdDbDjxH7ME1henLlzFcd19aAqnxpsm pQEv2Z/SB74FwSnpuR1DC2nUv9d+/bxCN03VBLv6jzcO8w08rB81gGdr0xYd4z8ndNGeZm9M QvZMFlrTXf5TArD/Wp9LSbb8OE9QzeJ6gU/8WWE9oUgt/9bfnrhofHmsK/+A4DR7yPhl6Wll oIMiCJvaWfY4VeU2Ex1pUM/JX26rBVZbEW8F4HxwlaP0g4oc9eHUOAn/9bkAehxWFw5bg+a9 cktkgvoX0eeWdwyBGeMm3o56AGUV7s7yo/3VxWWuAmQlHS1SBaPIUvHhqV+fjlXN3BBGMfiw p4mGZsbbmsFdtf+gWZgO5ZLS78bXw0p0EOdxOHrBpIxPwpZxqz8SllqTk0oBEgui1hE1MusE dhswYSAB7/bgIGGvR6kF6NSmNhkfmP9V5XmJy9pVzWNqsfKjxHKHvX5eplr4EyNIQIXYKHUt 6aYnsIYdweU3BAl9pMCM+6rN6cygBhTkKdiTYSRSiBP5bpbP2NW3cXPfKwJO5pIdcjT+Tdn9 4mV7G9VgYheKR1ykHEH50qlrEAYUuV+891jYjaBfkHOCBWopG8H3aN+yG2M/7U9mYaAZygmW IgmtckjFSYIRMcFeDbhuZJLNFHnzG48IyjZFLTJDCQPaCVInxaJzkFkL3I/B/why/YPJ5CWT yIHqQh1VmVKuHJ8D3PjUVaeU++PARRhcNoH+cRf53OCkcij5mUcMrbZl49sH++wJJFml7ivZ x2hMohwz3Q43G7z6VCntbR0MQRPHfE6svOVlBe8OJQ0J3aHdEjt0O/o9K29i+wHUC6csaRkq rfie+9/7HSL2420PoFSqcpdoWZ6juBs/9H75mLMURnALE08hF+h+NqwKTeaZjBVXAXBSEjP5 hBCDTdmum+a0msRmcwnFj55RpN7OG+defem0+xQWrUL8bWkpSJs7A6irsLpSUgNVHXCK9tUL f6x7mFEI3IKeDOhE3MTfiCPaIPo2rZrV6UaQ+ptosFPNipUgQ5fO0um/T6z9BEheqWCTQiLZ tRaNqQS1kqnyx1md8VYutof62aKfK+x7Qdl6xam2J38L2ojZ58s3aJmMxFvcou72rxRlZWag WLMnMExUoxrScNfgGuJm6liTHSk/71q0yfKhKyuI3SNfVV/e8UpaTgm035JMF6gPriTRp0ah yqNHDNH+nxTnazAzv4xq3Nx9Gu8IVpwDiyZPrlKKUYw4wYjfioqi8Bd/zA1ooAXW9yw01tUG qX6UYUxZmc2czAfv7Yk5C+e0XLc+Uc7f06lbChgLVqwbn7XlP5WHOnfNN0raUlJgkXtfN2k3 xpzGeO6/5ClPdF8AhfMUSuSr/Wc49Fw+UYwE6HAco+fheRG/NOKYBS7Sr2OCoAKC/SFmv3qn +Lt1c2INmL4uuTyYD0B33MHO6/G+bqdwDMTxNaaJ5qk+qy1rBhQ2sGpCm6rVNxAvOa0yLa5p UhNpU396sa5LqqAEknwtu/YsYWozqJ9zx4XCDA8uY9v2HbIpgdb0E9VMHJUaIPzYWtIvDqBO veu9llEnAvXFjSyBWl5ZBDEQsJ4H6eNZxvY88I9yrRRRJ3Up9DD1iX3GZJQbc9R3Ja1P7VSO huHKZAX1kQXESynzWu/T7HJ1tquL7FcJ32nfbqsMbmrtJw8L9IP5PaE232Vz1CazONoryE9d Q9DQhBlq14gNBblIw6IXXQKhrwnJFDHmsSxllwltb85QQbOWvkenL3iqHTsu9Hn3j6RpItv3 QRAD+6oNMVuvhXVt/FCPur8PTkqJtEdx1eQ2e+YDPBSes8k1g1dszFsPqRzB4znXZGPRr/Fh 7PnHQMVh7ee6aAJmxkQ8gAV0yVVu6+KiOqa9JK7RZz0iKJIjL+JQV1/eE5ls9afvkaype5AT veNeGCVOSh7YOVffjLkQfwim3xUG3SlkNud+HctrYr3VA2eldf/7P+eGWhXWtdC9hAGFDDI6 f/zilRmIFG58giUIGPogtn8nFs9nQtqdySspoRDwVXEqJA+gVlafyN0IrLCKruRhQ7Xap7Nr q3D2fuNTVhGex/tFb4qAoHEJx2GqV5RxrtP5CF9ZfAfpdUCQ9glgWLQxip0D9eao2ldmx7C8 8QN2vQqzWBLFba7ogxIORYu79D/ZWqE9BYDJ5SgP4wZoCPJRXppWDn57EaPe1yyt4TFsiMvX tdydQy3W8xZi/2u4GbEAsW99b44B69U5S0OXHz6Sr0p1EZu19eomVHJO7hEF6ugpmdhBslgp gSzzD8IWaniwdpWx8rWvh2kn9C5Q0/TUmseuuvvbf+/U4Q8X9Cv17oYh97lyWuLq/t+jrUBP 71WXJTogemPxWS1A/aXLPDPrl8BJA2xlsdQeYNaOVDguIVQcJk50XaxplHoBBtnvMs4Xbk7K M5FccHaUhbDIQAiQNb2tDgdoeHDDyfP4L5rCm6twSnKOHq1C9ESYTMp4NsYdOzlYQZWmEccw sdWL7lZGbKYbLa+OPNLhlg2SkuRf9VpVupM8A+dewoImm4nBM1s3SWHE7D6h7V0VQsXw5zfl CQfi5FXCm9xErVTMmL59Qeo49PYxoM4lgKf3aore48ECzEH5wIqVwc2bXVULilCqXKOSJhUw v1Wfx8c81jiJi8FFLAvqbE2Hg/bmkCs5hhHLSjGkfq1Om17EbEWQ2ZAU2agUO2C2T4YDM4uG fxlbAxl64ECh9P3qBn1hhtrTc3qiPHKdTm3LG+AC/9eiATD6oHMAqC4FB0HkpbXbCcwl/NpV KE37GiH9+qSfz1blwYQcsEYsMNeX3Rxrv+cDigIZn+In7MoJLMZ3slxmeclgTZmllAn52jUb 0o6Pxo4G7kZCYCERrxZw0h0xnGRBFUytAUFRawl2uX7fF1TjQ5HKHfvm4pwYQiUawdngL8s1 lc8TiwFMTWLztYbdO8O77IFkwZUHvnp3oEi/MxwG1/w6TL+90DQDvFpQOZ8LGXXeMI2VsjgJ x9NWmPLhVsu19V/A9wPSi1bEzUMeKQ6yYaZnRwXpMCw2729ZAgzfX9FkgDtmXVApcaJL/+Op 1RZr8wdLzzy2A5a/OwM1B3ScRvv++e0uHqzSG6+Xnb5I66Q3trN44oY3ltx3Gu1CSlVZ85fT uiu5QQhx2XLO9+HTTZKHoYBz2prKLWu8U0NELuNi7U/8JcE2XhK1yZWNmwYSEnsz5selql3/ /7Ja5qr3PLgkgPYWL381ZtFhMQJO416ySczvgrTaGLXginBlSYZXt5uxSC2WVbI88uEYDHSX xAqPSu3+Rygpqd/jtGuRhQt3u11PUrqteJlnD9QRclltaN4a8pka+jf/ouq9IPXYudiYmjlZ NPt1KWFcmFkPLI0OyJNgAwbq4oDMO89pZHKbA56i4vu75LlAj//TknNdMzAw5dvLRG8JssFt zfWduoN5sYAuRmC2IpEHPfWqo2HDHWGeQneTdV3PIIF3dWF7Np033ymAeBJJ77gmeFr2dUpq wFWt/tEaV8nahkaZ6o6AcZ8PSeSJAAtxz8gAlUzZITE/mZccO5FyEH2WzyOJMYanA86kfL56 R61W2c0gUCAb0NEZZ+XOU0AoSpQXnynoNETNRsArXw0y0hludBJWc7CAKwgxEYSIc4NJPYHo +5AewOPOd1nNcuQw7YQ9Y7xgTDQMvTQiQMaf5FIOoX/fCduDnOPMQQyhXEC+vaot+5oXIqfl j9It6HfwSk6xbJWbkwg6WBLzbSNktVDkU/3yFQdG7iYD5kkw9/YQP5lMu9jCrCNi2rly4g0t 5Gnr+nh2vSpQOjPF0wvfe8tP6g1cJOL/T/9L/ukYeFoObYDGx/edvn8n1jDvhMmJyVWnN+9l x54n7Se+OBGJfS1dSGQUpv0MzqOh+Mn7ofz54QyeJH491XT7/eKHw7vxqdUqL5ZkSMwFOxOz cnDExys/vomWHkmPZ/c7s8trlDvEg1RnQxHXhPV+0yeioifpq6Xn4yP6Z4IDK8JRcjAVsztQ 2EjECKeM/rvTxw5iU2m5Q4dTY7qlrrODBc6TDARfprLcxDcRfGpwOZF7+v4SxZOi4X2e2m2V 5k+6ONSqpgadaJWK9jhcsVY1RmyffJsLhW9ZCthOPyt6u4AyMvUVvK9R/1J1hX5zn3eYOWEj r9GEr/uz0k60MDpmIkn+CQB8W57k9btTeQDlxzs+40Q6slM4yBhSaRPhEnrjCxfd624ybZXq udNfnBi06A1d9pqeWe/DRlobXywRmKcbnbcHWsUaYWRPzPGobEAdvJJWzuOgfhnZPaNbkzrp mgHmvj2S0kTCnMDYJ2xkwnn3LWbeUYH0i7Ol4r5zNdxRFfQr4iRkKuKeFZg+ikGZSXienlVM SCChia3k2rxEdjGcL+jqLoPejPyokTwJneluoogyt+Olug1xgt0NY7OLObHaNDev4m0QAOGG OlvqlpdUoMdnwqTtoHi+pMJUK6YQWbCN1kKIxGqQbi29CRlmcY0jRWHOhgF0H48988e+6Tpc ciDcD4nqGiKgU31feyxGZttB49urO9VmWWnVz76xXkf4xrLUvUXqAjo+1POQTruOzAjMMV51 ydJvzc3tyJ+d+PvLVl40HgyXgVWSfSPQqhlh9fiTjhXAsi/63ky07Ahjh42hz9G/3ukjnX1f Npu+Jot7OkdpbE+z+BsnyMiwEohC6TxEQMhhyKeI87tzCbBfKTH2ZC7qkoaPcNn4U/W98ssh u4YIZP6xmQtMoIwmu9AzcPVdMRabmEa0Yi8NCGbDRiwr1QjI8ArzgXWlNG8I32v58b1v4x0+ HdT0REUwx1UTMq5f3U0XhrkOTU/9/fnLS3FWZKLJkE/z8wAShIi7H6tjR1hQVXyqnsdvJ6/0 z0nzZzPmL5WdYUaJ1/TRU54t+SjZzL5kdfyi9iRqPbvE9+gNfLmXPNx1MMhTI3WuFVjLAFTr l1FeZ3gharNdYBhXsBN1uDtdDYYpwEHT0PQsMuqsUkGreUEVcr8LF9NLGjkEoNbOWfpveLmK KLGoceKFhWThMpkKm1ygsf2/naRchanuXSdYuXvOrnA42MiRe4j9Zfev1L1h/Xx5tmxz6G6G NlV0F36ptPIBeGwcaS/iVy9GVxbJ/GEKnmLyazdlqL9E6VZnMWZDyP2FDYP6n8vY8t9cbBAN iKF2PQeyiGfY1G/wGNmAHn2BYQP/uBhS769R4QoS29mVpFJhH+Ag4hrtIM+tkuZFSrf/zGAU l/5Aqg9/DYgXtzj9nnGNvypIy5A2PMRZm3sEZVtMbp79BwrRAuAz6ed/dsqwsyb0fGXV4FvF LPLgamlx96x4MwGNOPA7rQHDVVEvxg8yAIy+Jn7HGFGcqCzgQWIvQyN+HMPGyRmtOXP7x9yu QU1+tcbW0daeXOmhld6veMQYplRLmhMluFydUmzqLZbg0c4VTJwO0+hGQiiefhIPLLMnpHWm YpyI2NIalGMRcJ+oue4BRsUo7EalV2W6rqKMilMP+2DtvqlgfaGpgqjmNSJOoCCIhcvwnJyj E212xgvkNoEXCdTs648mtILUTzJG/80ABV01V7xRxuu7mag3sMJPhB6pqNC1Ux+Og8PBAE21 eW49VO0xSZsHIgyNvjzyEMHyyZ4BnFmkVHRjITPLJuIrM+M8lOxF3PmCXf4e89fd42wf494w MVssBgmHRgw4SZHh14tSci4q1bXh2JRBfMxFFDcP7VRtJPvtzNd2UoOgSuwp97q1bPVBpd7R LPOYN6bWNHJwQk1TPuGY7GickNOCWFqga4IqvAdSXat6EC/lxOomBNZRpCWr7oO4g8Xu9tST hHjDl2cwq19LarBYfjWf9kor9KRMc4CCZZoBSYe+DVUUGT56TKLcyb4svsVDHiCRl7uEXLAo V73fgw64TiiK0Msy2RUQveUDCyK4rOvkqlOe53n+hd4ADgXbCauqS/vAFhesNy3osrmuKN8b RtzSxhLRMAnLIPC5Cvu86KgMXNmPr9pel6WlXNBWmd3zyemNWanOO8/VQqImbIg4VqubNP2f CooXIRuZPlpVcDVjPKDYC1BOJsrEzVp5jkOYWB87lTL3OtAV+RKcqvK2soOSgb+GatT3rPnu CCqsJUdln60kl0150aq/VBh3UdInuruR6ldiuHIC7M1XkgDL7PTIrxlwgCBiRakZjIThEtkF cW0KRZB9hC7QjJr4HSG4dHeVBeNIpe7RBgeT68m5iPLGdrhJ37GiG5CdPJJPd3BWddrg8nd7 qi/NgRO65Xb2K4F97IY1HIk7Qs07Jh5as/oK7IrO9EcU1tQH/U4wN54xGOgh6VfVXbPS/qKA vq6VKqefkb9ldzQmuZUDTvbqacYAhy5aUeY1DEqtaOYmWY6v9YEByCXJppU9bZXQLr1Wrr2w lJTCY9wRlOZR+0flLVJeZdIzUN09PmD298vsxAt1Dd7n8Jf4GTRwQ1gc4vo4F3Yg1e+R9XHN ZTJmxm3ka567tgUbw5rhj18trDY4TlyFVmC22kR4RYrKA8ENf/1VzbWvJDwrgjl2AlB60Cf7 1D9HXToPKJrOlLjYsyXFQXcuYJ9GulPd/AZ4TCNVf6ZWtxqeIcgAcgc6wPNWpKkcu7KrZmsj EZyVy+Pq/LnHNwtTd73sKeqsECTM02dKN/OcielFKleXs7rUNiCZZ2OK1H3L0pi7/zZj0oaJ z8CgfCtlfjakZLjomJDHHXxPy27cttLpUNhcxmfahaFb2aLZ+slSjUJdLZpUHuVwThjKrRGc gHvLmu0ukfmxjREaTfOkYbgx4CHfbF9AYksFHr9cOvz6SoKfgwQAUcTm+JjB+LAFOXYvNeJK wxqp049dmD0m22b+Ksx/LlkA7mhLjzTwLyYs7M6g1Yl5hKUzp22q8Cli1O2oYyMp0RbBmXli uAg/DUdiUTQ15UD4mRORMgaavz8fz3LSrajaFhfpQbIMsocAf+K9moRDTCjvs1cFK7/gNO29 IzEcdDVJxhkg5Xj7BOUBv4wcsD+2J3BXoMWHK9i4MgicG5D/UI2VtbyJpVGEVFzn65077TFo ZoY4HfvceTe4Y9ZTpHTkwzJYAECT5+b6mhph7vuhDFoKyAqyEH3C12Wc7lW7qqAqtFN/VMmu Esp6q0LevfvE0GNF0Cv+hpfMuGz+0/zq1RgprclTCoW5Ppo8LfTjjOamaUaNDHph9yBA+hQX OLkkqtSY5R+0YzZWkiq04K4av0qRiH3isOYR9+rB+vxUQkReCSM1nMyoofuT7lTSwH8XlMbZ IxXu716fhhSx0nuuwYGQQMWLqukg04uNpviIYtT6IcqSHQXm632V/Pwg7T2yRov/jnx1cMqj HnIiLaCgT4suOK/ZZ76Z0XIk1Mwow8Kycowv7MyqR7dvspZyvby5GnI6PmUB0pVmS9b6ygoF GWEeFMrTd/9g4COP+JUBLFn+/SYPVVQ4YTG3qcyrOe7V1xZCC2yzul0sEn/6SqyphWYZd+Tj cM5MU8h3XkIW1tPZo/LonZXJlTsaQ/b3eOV6BNSgIO+gwlG5Ma/qIQTSmflGO+KKLv1cxC3N Ocp58lRCKqyvrBKFcmFRrZngHasUa+DP/YR9qBBRejAJwZo1q0qDbPVJi+0WsYT7Lwqpm/3u GpJwEUcXn20RHoVUO7RBG+BuQ7Sfe4uyrai0sniONXSuLFSEmGu2wBDdbsL4TGFEEq6aomKN sLpqwptU1HY4Sfr/zDFjM0hkx8Po07cXHt8hepjK281azDflPaOEQD26dJf/OZwxwaERrGLm 5/cXv76jXD5104Q7Ip2ly9ceDcZ/N4WaIxB/FbGRRxmYKXrRhCaVE/tNvhu0mRhdKIpzfSHa On53kFqAceQf7EFXiPNcFtJsuuAsKunvzFcDxFvLx3nZcW6oDooWhp9fFAOty9BWfZdHi/zm 1KoeK5/r8XpGWAUIUbYO32iakOxbYGLYfXIsla/x4FrES2CqehmoUJCrlsvJDjV1k0oaXtMO fmIwKNP9Wx7ADbbOPvABFp9pHVkkGrjnGVcP74cg2qpxnhKXRgwCy6oAh3hXUPBvOYkDjJSC 4fJ0K9BOhoTqBBFmXIszRUFY4b2Gt2AnbJ5e931Cn5BMeqygnNrGaX6bCq1ItmE1dmhs7Yob m1NcXvH6LMLgqYC0V4cjRN1slX6unVFeQjOFhqrfzgek0r6b+XE7fKK7w5OZnqsl4y4WPraw 5Qo8f2b17E9n84sZcgcMr0oB3uJ27FRhGCClGwYT0PeQaeOTOFJ6DXZH3dM86H9+CrtLmJ07 Pj7SB9bhAH6uPP34kOWdpaC9r5Ij7FKDMRk3riK5yuSwGoLp3ETwpkdZZWIwx1G4Y0tOeLi4 KQt3r3yfBqk64YGBmQzxto8oiSNF2lRlRsOIa4Qy+M8FGu4eqzkCel5dozdm+WOhci2RxIdG 8ewS+c0fkc+FqTfjrCR1V1wxT2GfpEQ/9fCGu7fpoDYNFD11Od4nkWWutpdMLcEG7MG6S4nn faLU/lXZetBBPLYsI3v6Law7ONMl1wlcW4vMMGIgglt3j9nsPBPVo/I0d+p6GlRVyU+BPiab XI0LulhVhAewPTAxlAmMokgyB0YxNWYotqfHN9CVxI9bHT7CNmw818E6fVJJtn0dRVOsmrpI 9NgF2NcmEmPiyMTjN1Xq7UDmyzFhsPGRi+TzbbkjgViCsa3vlqKTVa+3Wfing16kghutwnc/ GiLrEuXhUEKub+4FTMOSw5KniURuhhd0nbKEGCB/ocs1SAib4h6KsLlZZOsi7nylBUsFn6pQ k73DQDc8Yyg+Rt5EZz1mSegoacsuTrT7AnJ0fLepwyB7jVmVbpskpL+z/Eb/nWojnDeh2u0B vTed+xGaVwTjPkL3F6kKzx4+Q3mZj5VGVv+plDodCdFboXlta6W6toMFd2/M9AqHwfjpiaJ3 9OdnCpm+90/otU4NLatWe9emd0xAB68jmwvfnC5TEVGKyP55fQ9NmaPYWYC2W27tsPNh0r4n uWaT9d5hvO1m4RvYsbwG3sRkRavsy5TLhbM8X5lIMeFhceEDVAxmNqOr6l9W9IXCgGeoXH64 JzMCRQYAyv23EpSFhIJZN6pnXEvT+QhIcFhPE0xRUatVgd8drgDB38hIxQoKdSB+Z81BXpgc TW5Yf2XIA+XjGfaiQEX0rc9pJBHXPQD2lwH3XIo4u9bbcAIdSslrpbJNEQm+uK3W+y7Gvnjw xxGZhOEFMVET3xHwB+ZQiSWnXTsf9p5wJBljnTvoxpdCaQxvxCwAQJX0+buEosdonYb3BmrI n1zVAUK8K9TuAMfFDGKq8ElVcVBawv7mdwikMC0oAUc7QQVhlTsN8ro934EAJJgA/dr3g8YP Qm/ZEXQC1fP2GhwLGSGZC4Mldm/3kGjyO9hOIu3U9azXsKuW5SbKDLV1dNMpkiPnTDsiBJW4 Vygo1FY/5o7Q2BDDijbQZJPqvX+8E+1vbnlGADMnS+8fm0ms51V+p02z3tcXR4qh2oCN4lCf mMn2CeZTQxSFqRTzH6WfXcIvV2UbwC7Hd/vdT9+UFxvyluVgEm3zSoexuXmpsJW2LlpbY9J0 GPxQhFHFV1MGKlInijEH2QF/+nIKSQRypghomRIyuYRXo5k64dtKDurtgo4ilMgiHbtykfNu T8+T1VRHlcPTeC45zw/mb8dKyJXK2oFz40F1cVIl38XgshHLLTcnj5OnOHJ5ZWSWpbG42HOv rqExTIkiA3Xv0XJ59Rn+PWWcNp3zuT2a7WelRQPxpS7310Yj6R3XGAG3fPmXlKjp9TtE7dGY rkg5kXyP2x6B33zaTM7Dg2/axx8WjyAvsHZTYkPEx2cqze+CCgzBlqktmL3/tjXFAQsoorqq mndRd6aAB6SeRXZ4CrrmHFWERpZ+8RePj50Crzbt5vlQUgqm5quZ0aAJGgv3+PKjJ0R9kxXP /kJEytbaeT4UWHHrFaVI09AWKaXLctwjELa2GUp/Enofl2Z3dscu9w0jXIlDmyeaoq8glZ85 X/jPijtkJZinAuE784lICr3cFwGuoU70Ipft0qkMQdmfkvHR9f/efvDs8FfmTC/FJvVdMYpa SX5hk/WqC3PtK0TmWo638mV+EfKaTJuObJwJxqD44l4S/6x7v/Dyph1hpFeeStWtFms3TzOk p1bAS3MD8a+WXg7KyLDwa+1JPCemXWfo9Fdx/Vx2SZcJn6X+hgYgZb5mlwJgshtyLmcUJ6tc B40k+41V5sZl7nd1NlaIcN3yZzni7ynzRJ2OH21XruHS3XH78mPCksvart656ZCK4dHtmSRc 8+tayT9tGPWKwrb9ml6o/9BYeGLwRM3YZ5tySwhtW43XNV2lmokfnpoyJsHdLok7plHwTypf a6YEdxwRMGkCkXn1sDb04syPginz9YVnnCXblXvq9Otw1KjlEJos1WsMSZxTiWDY+utJQjHb pzEy7paQg/s2NtCKciFff7+b/73RNKRxM4OOjq1cMnLsq9VhiVn98BnSRgMl9Yl73Lb7KPOx FuiIWDzIYOQk8+T5DLt0z3ancDXD/EQppdI8cWuz9JgIlTAT2ebuORy/VHEs01J4Yzj+6BfC sk+GCewR4hkzR1NMXfDRYqo2LYxE+zk/juuIh+JC5369uPTKTKG1lk4NfhKF2sxVgf70tICJ cZV7DOyfrkj8kXk9pScPKI852W7/b8IqpfhL4jBPqLaLUsUDCWCzFiLpFmU9RxSPbYb8QCiL 41vc/E74Mm57HTjmVpRg+SsZA6SnoFfMVMkcoF5j3LoRweQpK1W1rzlpP75jmnJv8N1SJeYt vpz2+SGee0mq5oLJefJeMrmhKQBJ300jaKqf2d3vmXUm2xZHuS+fMEmQVfBNeNmD5loVPf2w C+d+ZF7kBGKZDhf9D9P5R8v6sjlcAeBeQRQEHrt5zgBtqLbS29uryMdjT61YwD3yWbUUoc4k kjXPTEPSlkwvSYYPh8CIBY3Y6lKZzZXV0d1WtpMMp0EoqQIxMlHiL+RsJ6gQNwjTMRgu0/Xg bg/2zKISGZCpCSvnZarT9avFo++mjDpGoWt1RtUkpk/xGiE/lcHHxqoVA5OQFDob9rIN1HF0 FPtg1qY1yET9xMazdk5uUxddQmPWvHiacEpZ7wZpC5SHtDKDj38Vl60PX11zSq+ivPQgMojz JkhLo7GUY4UseOHbDljjXdHby73fbiUFfhgz7u3SiEtXCyfcuN5gvBPzkXlH10Kf+itfLMp/ w5N2KozF0KAmH5AUVnHrTc3uN6Tj2IzC81b4R3HTnDap6kzSq3a2P8K1u7d23ZowQ2FMYUl4 8HGmo0IgV8zBqQCROvO7KZWhwk1DBlhL2XY5tX9P3WeakLGGYaz+m0jHb59rPewdluKMSrpX VHqCVfoAEZaXEkge57EFoJ5hJt5lLD03s4PTqJyKW+MqMmRpIY5qnwpo9ZeAnw7qju+4aOT8 GDNpLaHQyw427etNY1aTTMNmPjTbGRkwPQuiT1iPnCm3OZOSU8qeihDgmhlo6p6/EHeSLhpb rSYqPaiRTEm2Vcyv3J7u69ZASI4j5bf1E8fDBCYExKenBDU0ldQohoPhclwjUfc9oqqghbyh 1ImnOtoJv9f6ZI5nYUHg92Y89UCpWi3vCRMDgN5feCg2KtUEBsCno2cYGSEgZwTO5rhQ9dC1 6AVo2LHrnKzPIQ/Jx6hhtwKkJ/L1gBLSUYG+EauF0ui40GPigOAMCPiIOkODtAWLhCmYXAqU fCjN0TZ3HsD5t97uZFMJ53Sga/Vp0HjJjmVgpTvKSU41y5zWImJxqxPg39u6a32sQXq47nNz hiFofiJcfjNIHEl5ToKKuOwxfoljbVGDiwrn8fTHY+tj4jyN4stn07/qLvwMSHzP20t1oHy/ BTMOAlTIO0mlnPifzTSxhSpcvZV4XPkTJjcA9PSBNw/T7jyD8wTwZOsxh8QRdxlr5FrgyYKL CuSTXHS6F6EyKZ7tdA406FUhL6XMNWjDCbKcYtOod6hmh5VZvykyvaFMFYQ1/ilp6Djl8Pna 7LNr76II5S+RdnDydd7vsdMOQliqMzCqzhgIvbDSMMXhpeR4x/E9igcj0buvyW6B8RcedISF +4zbyTonqVPV/QyQ/zCQICYm4DksWtNVQlYiyBfXCuo05wag/MYtEzJ1esYmQGYrqRCHVF+t KCXLHT+AVb61ssYwgv1s0omKKwiRqO6LqvdyUMia8llsRDp2Ei4MMPrH/lyB4ZrtGazbLhIv Sqx2FOXXvYF8NLttf4Ft1+mwdyX5hmd3ObzkePlMXLkEGzhqP93ZylIh6VBTsv6CshSbYlpt Mv9cezP+xtMOnopKvBoTorjTuEmkW7cjvphAsSSHhc/acihmoAUPm8pdLusrADXW5AT74J+3 2UeT5dfygWNH9qZpsjsrrflNnHSPT8krcD7NuJstk5vldXk+/5LMzJ8auXW4m+0Ni/JhBZ/O VcW3uPyTllNkqwyp8I/5xKraOgeiBcufZIitue/kYj+AH4SpAnTP7FIP1ZAySNOB0Xa96WMs n6Or+vccOCbqDQ/hw1X7J9dhhZN2U2sFjUKsw1zRLSBb0ZFJrZXPnBJwzlmhjkEAgnNNntR/ V5AwU9DQbI8Ag3zXuGWBbPbTQmm2D4N2Sj0W5TlPmVp8lLiHo0ZV08o7Lf7xyX75xOPGp9kS DEwqNdnwL+KJnVnV+17iH/gbKL6j1BnH1xRjYl/pAdRn2rzGXTZV3khuahUnL/JOlw+xg9zI lSAnKKwGdbhWsfye+4FmTzm2KyrABkyTJzd342ieadx8r4OrcQ99iBPm7CrbB4Zu7exQ7PCo CSFahSUFnlJHz4MIyLI2+7B7kPQXio7FKmP/hynykFmLESykb7T5/zcV69u+RstzbMBQFMK3 29n8ajtXBTzX0RVAQc5jq8YvE+xTH6PBbjnieOgYAvsyA0ZLwQCEfHkIVwB/lq0mubidHnar 2I+3dGoYeLtQrjyQTVfexzyX36bYdBXTb4MAeLxP8EPBcIAaUbkTB3OzxRkp+V8zFvbqpKbi o93f1qVQMLM1oZQ/Yx/F7k351s05nxZdZLXVfVVsqWgrUhxcprpVxNW1thlMYtL/bJP1gXao 1QWB8bP4srlurpbS2eZqhvd6RbiEsX/LPwNG7MBRkiZ4In/G+iFqvt/JI2KfqyhCw50AA1ra aW0oHnoudQo1V6fINM3qGYfwpxH7aNqZF18JO3bHAsv6nfflOb5teR6DNeEfm9YuFF4yNmfh 8hpaHIKdklfXJmLzdiqu3oPHaimW3PzbdQO12yVfb30XcxraiIuLQ8w1aQfcxiF0J/bZbyuP 7Hwr+auK3uK5HyX1pDSfRzY/5QBM3xxxyqFiZ1PIVCm73WKUEYOPSwKthogoOYSkm7BrOBaZ VhXxtdgRTYuAfZ5aDr1SZBP6f3nSmvs/Yk3XEoKcAKeT1qpYcdCtfsma45iDnCsyQ6RAckgm SFGHsIx/E7t41ngxbm5v6Yv6hpgHW5rkJ580abzGHRRFiHYVbJPsb4SeCldQP6KYt+kuV3Dp QhWA+JOIIepdn9x2/h6DjRY0O0DwYZWWQukvLeLhUWXXN0nQaCfThGmJTr4rRdv0werbiYoO zIALQavZ6IwSeHN+YH4VnPyoYmh33OV6uUB4rI+VM1Shsc+APNGpOxHxoWuudp+/t7R4sxEK 9Dknp5ZIBjXu7sbMnjUCKuTAY3MTZUoKJpKOhDPnE2KkF9atDzWpywqQ9KRwHIpXZx/EWsCl Rpzyg5iL6ljo0Iy5QfaeAIpUgdu0FI+UJxcnK9s9fniSZaAnHY/kbFgD5+/6wdor3QA2h0uD /afZI/HXzb6eiEwmEiieD3+uLf3Aj8Dhdj+moizDXhXghlIVlF7vHiq7waMyTL4HyI+XP5bo 7nq0FUobd+t8pt9xSgTYsO4IF8IpyLeqa4u2pkqT0zxZcsvSHQkFtHAxJHnN1HYfZrRaSb6N 1NvHzI4lhf2VcjQhbCNO09Ub45aSO/K4nzjCQijXRfiCtKEA/OV+aHAn07myYEjwvlGBEFBm +artC8p0OBFQRrp+RZm+hp+3w8vQp6LedqAyH/lQ/zdP+cadOmfIueEJPgCVqY/mXSivLRFI S5XOJIlVNRMiQDVPiEu1q3IkyiJOgLibmT57byqTCc82CX+3css5lKWdYyhHhlHcaZgLXp3s rqTWVVAMrH9HtBCM850FksCsNsSRZmiPbjlEh5hMrqX4Jip4suRAfa+uPuZPu1n57aE6P3Bc 53muGAkPvdJ1H0lK79DrGu7hbZv3N08bbAaF/MViy9CUW9evDCxeVQPH9K+bE9Icc7MWRaYZ YMEjJcJvMehr7fN+qmkfz29MdbDq9MgUb5RSjVr69mP7dJ4RuCy8pbTsY8jC1mrQiw6bhnDG RNpEoIIeN/Z1qxTxj0syaLXLDV/8lFjzCbyn6NJvmWxBpWrlE4HiJT7r/2yXVyBMz6cpyeMC A/iQSwAcAoEV5QaeoqeqUtavEFZOouGxI1n6hQhT19c6bwAn2c5Gd4EsAYSTZok43piOYueT TP7myRtlP9WbpmLG6M/wGL8RbJdAAXWP9EI7kRTv3vOCKa3wIIMpUAmMnqRQNwzzQu331o/9 +/dpZOwpUpVBsPtTJT9mye39SGPZ6k9JywB/rR48wu+bU6Sio0wNyVCkh8CEAN4Icu/hXXQ0 zi/4Pb2XP3czOdLmnMUYdpn8RjWXYk0LsqOrhKZLLcCvYeYyUMb+VcUf9Bv/oWApbpCg/yiY kTUTfk+sw1TK1H/Bhlu/TGoDPHBTkW0UmICr9bslN1Pz+3ZIkVFRWWB8XYoGOj6rhe+AwEzw rFHTtDwMLG4dOBBsbPi4CRQnwT4ey1PZoVgaVDJHkVOv2pIV+tw1pFMCs7Sh9uLreTQhelmm 3iXJnITLJ/vHF9aZK9ivScdIWrgfUHU43VUX7rpNFzFRpyiwitN85/nxZe1NARF+3PZT5LCX hI1W8e7QeQGrqyK68Bx4F/w4VC9E7bDWd/LhVY6b0pKlOLS/Y9hem0E+CfpsVNOm+BeZVHyS dNZ+LT0W+58yRMwgs6ZKsGmO8ETH4JPAuTTKzurhgMh6PC2IJIX08ajFpS7JigyaY6/nCpDK cryC+j5iXKaA7wvhSEDMv+V/a6aKBesE3yxCcWqDf15bNlpFfMVQEWgW6cOTa9pEzIDXlg6K tvCbLYZ8eJkxSxi30M07zfCy7x8dfxd1EA/TSa6F5dNBGOv2jKZ+Kv1p+4ZFZdgGHedVUBFN SM6KNAHK+bEJm1ikg4sdIH1TSoi9cXkUm3fxKnOoz9sRt0SoMjkKzhFZ/EdMN7F7bZbGELK+ v/lYwStVAtyq9MPYoLPUNuyav8FK6WRm+CxYQCxQE/daCR471ob3s4Gq39gbSyd8X6MbxjT9 jPdk52m1Lv4nVVmfzwJdcWcVp6s5DAo1zHeA7DjMAF1AIgrTBPrdZVXQ5t2ePCTuLTyXdmIn AWzr+t6yAWt17uyVvFLYdPwTtMVwvKwWLkZtuH6lby+R6MruBYKkkJe/K7B2kvTxrgpgrI7h ZfYnrj/z260l3wDiHiaBSSlh5HBAHkK5SMqoXrJvnaruHp4WnDSSQhWwWY0XzWKzjhRhswO5 gYK1FOaLskdsOCa9c974Qj/jzNiTbC25eq7IWITbABCHaiVk87e/ZhPTWqopexfpzYC04wdD xyZLA9blfqVNT1lvp7/jE6ryXUnF3BpYaZzpeJP2Tzk8aVfZetU926YnMVKFGD74xZEsnUXP srDZ8wXMJHIyNEKAwBIIsPHTmxg5k7OsoQ2aRSSC2JR7nVJB5Tgvmc8W+H6e825Pd9KlbLI1 ksHCba4BvCcd9XIu8yUFxnXNV4MmLqiBV1l8SnCnMQhRIq0m7Rhz89qebGHke4kp3zG1le5a MGZg0ChoxNdEHCOoKPslS01xe140pm/5oEVx6yCdzl/lXMtlOhOgC0jXj9K1PHRED/CWyZsg ZxQbDtALRjTWuuDR28zet5ZChVEWoBfVEBF1qCZfJ8DQc7th2NVTngwob0kgeB1pLoYJmrjc OcviLF4yq5usr/AomHUWIp0eFkpl1K3umyc49qkVUNWSLo9y+/FT2FmXpdEOVnMa1oClQyo1 YJI6Z2AsLkQgVG2Jupr9YClLi43d2r3MmyY55A+qsRPMSpbAEZzWOJSE5cOkDHfZDpyi3ucG FglV2qpYvC0TVlBcYoxQ74iMaRtpyo2PKIITtXTxmk86M377V3ki6y0EaJbZV5kZ5Li6HhKG J6jiy5jL6cIRJUo31GY42bVf6ori7d8LDmFNPFWvT5/NmQr99jk29O5ZyXNkxyhSQAMrtu0G MUD8L3ih1jJBGzMXL6QhmZGXVB0Oo0Hb5Zwk6azyk8Htm7ce+QtsnFlId4bekg+uI3UJxmbe KqTPf/WLcZxzqVCXnwh1qjYhgWhQsHszw+qvg/5YVjJ+ZX9rkpdaogtSWKXkohxhegAxO1b2 gtxE20UJv2zlYWk8yin0pSn78yZD0qjcWzSfO6Av19Sd6NvNqvAK/Iw7wyzX+Pf7ppbcolWh wgIiG9ySgBn1BzQZPAvAZsj9sYGMTh0k/QE6g9w+5ost5rZKO6gGbdKN4Rq9vnNYraFiZ1Sa lMZaaQGtKG6fnooWdEaoa3odJa+IcivmlZBLKlNUp3lZpJLL1JGU2F5VXyz+9jjGaWgyfPXX ogEN+YZFuTZxJO3xrswPVZuSMVTwowfVMLvoaZfbTGiteMwh988dylj2Ow+HLNxu9Dafv+Vi jZ78xoW5zI6M0h9iMA7FAp5ZZro7m29UnmfPlFtt6Avt8xp1h7MNyor2cGBRnVuqvfSFbEbO tKx4WgBddYHqNlPjhDPrFPbyXJMnCq3qfoP5zYrPviFzTsOvawMfkynRuLzt2IHeKhnWiEnT lQFu2F5DYTXFedZTe355au73wD3lfMKr3mXs0J1ooerVv54ZCectAFmQfRohVjxzKJh0R3KU yNVOQzGCBgoSmEHKTTOXJFinhFA+/alzzqiYmwxY2KpGGnsOMGYzpUquE00DGvMNUuPAYCpV NTGQR+f8D8bziZg8jIIjx4zsG4R9Mf6Alwtf+AF0fBP2CzQsQmAn7taqaMG7ZBFor5hKYzmq Hg+gV0fwgVxjqZJ6feHHWS/znLKPz+6RcqBHqd7kwKp3+ZESaf8UoKokqafGALmxk6HtB4Ai FMKFGYBDpi6Vcvz3Z1cQHXQ4WOXw2LYsENT3t16uI6cbGwbx9ZNEM3hfMV7Drl3WiJB0ruP5 XPKHGpEn8Yma4+pnFhtW8j/pg6PZ8o0pV7gsAnF0/rHh+J8yY1IlC3dhikxOT5qMy4Sy7pT0 jmyrGhljH+Hw6Kv1Z2/Mr/3JQmQOHbe5AlfEi5/Ad6VF50ZxzPq6YK/G0kynKkHVrhaefQFb BgTtjuMHpZXrKrC2S/RCQF373oDVMnRZCGMLNdtSNm15bYf5t+BeelCWavA8pKnlpwmEyt4L 8Vpb++c8hsOPAqYBYFwANjSJSK81FrjVq8lbsji4tYF6r90rM7bJGjKk9Wpajdf0cl6+rGFe pCr9Q36qoNyCb9K5SFfekJI+qnWgmyJD7MeEjOf56YKLS39QC259lUKwu+iF08gd7R5glHNd mZxgveM1W+jTw2h7n2HCxyfEzxFZJCS9AbaewPzBZein3Iu3GV9Hvc6I35Vho7pwUOIzCGAA rPRHS8/FVXZHIm4SOSbab5qguVmS/3nNnT/Y+Yx0Hg7eRs/SI7KEqnzFKpNT+NGEkYtkZsA/ //ibJoSKWBg5t+NLd338VWX00gDEnR97DTaEpOlSXkYEp2if8ykuPpeNU0s0VckDDg8NYm4v ARj/wuD8K7N6XSclIi/T0hasOomz9VUZiccmGNFT1Gb1TlgcgUJF+SnUp9Mq3B6iDGc7qkTy XGjlfiLZTRilTaZ4IlUNyFzjWYyEKdBPaT2NVwK6YteseaeJfBx3IKAOa5kUzUiVqnz9lwmw yPc2/5QxzyWxfULnZNwrN6kIEw3P3vTf1GtRJ5oe1Nwo/uSBoVtnnF8aH5nBvy821hqbz4Nc fTI6QgHlPTQ05V+gxDRPL6VrIW9JII2qdllZemaW9LnMjFr455hUQvR5iCfgCX17FPIxUXcM Uvi20RbO5/GayZ3pxEtdvokYZ7XtMS0emurQ2V4m6pWcV0aJbZ3P5sKjNXEwIoRTlLPJ6KOm gQr5JhoLt8XYDL4hI8/pXGq1FkcGh8r3/Env83SqQvDyNOZreVb38fYRJ3RylfHxGtdQMFHL +8JkdIOWCLUWQOUCiun8DqBjpyx/xASJ6k4OCFLTrEjzZt8Yo+Ewzcam5tvoShIL6BSRqzD+ 7aUDV1CYZnNKu50h4eDc0N6xDzupPRpWax22W9qZ+UCvI+kIfDm6dvAOjBhToJezNtEzGVKD 2ULwjmWdy79mg2mi6tXetpz6reDXc6OCVuTyzsy0+WxL0q0VKdOWlZRBFZzRN76frN5i9uMa zofJbhUSK+6NCxs5FU6eAFvdXxWhapsHDCAJzEN12T0HLNa8MIkJQdn2zgm/5/g9fh7iCHIp YT5+sG6b4Hb+BJNAxQsTozAweRNdOiaOHxsqpmcvNRsZYjTCrVM3LkLULutmcS1xhICIeRQ+ ByDLQWLWliP51J8qADRLyVr3DZY/+CDWntrw7xxjDM6qKSg+xd8H2dYMhPzcRbJXfM589oV2 QdS87L/TR2VvbrnajIgBJjUoEZplOIzsrcOlN+/0WHtxE86XE+T6q7ANv6OLmFS1MPfr2XJA BNkwYkawJfR8ng+7KH5wiJyUcKLi1rVD/3RcEKDZzTFQ2JRuDWqY/VJG/5fRVgPGS4nTMihU X0p6jvx20H4Qs28+gq8CcF45Xl92teHMKLdSG3zpAByw0POZo0omdT2X/M7nLSMMP/ej1hxv uwrYcjBjOTqADuIseMQ7X4Jj1Jk3LMmn0LxM6hRUUG6ds0VKA3KoeOshNf3o041TG6+AHcEV KKtUwA7oE1zZruxQQfIvJ/ogqN9qbn4lfOMznFTiL2pq/E7vky+418jSHG7hIJdU2bAC4Fe/ k0NtO2rnBfnMEDcID8XFZLmEWMhm1dbeg6IrSnVSiNeuyo2FI9IYK3D56HdaHBA7A2kSzme2 37b89uYk0ldSGmqzyuK48+q4C2muXKwNeTNJmPAPZUIKrPhE5TQLF2LNik/BJ/bLort3EucJ Ahr7EAVQd02KTDjfhD6a9oZZ4TALlJJimdY/5UhqHTqyltKccTZG/jdl+ouQrSfv4jCfVY6T WAMiX6Q3bgy51jpuj0SPh04wfh2IZoKens5/qbzwLLh0pCcawo3P++xZogaEgzphcTB3EflE krkwwzI2cEWJYS/bED1+BRnQ0Q2yuP2RJqppqfFtr39vF0cHsHaR+lIh28keodAZHeNx0E/n I5XYFS5nBPfl044DE1qtokadbQGbFyrkdmIjaITxObum25UIYkInwloQlY2G3VJ7aTKCHzhy fPZ/u2RGewjzseUCiyA0qxP/SkwHyyHsgFlJwQFqf2hLnt/7fix5gU/Nei9CVoxovFoW0/KR QqsFya2zmBFWVJ5pc4lfJpJn74cJRTe23DY57Nw6sD6SbAe21L01LyzTZMCzttEH0LbudoE/ cj6GDkwKKP1V3/nqM/Scd7xkBkd0sNCUdLveCTgJ55+Uy+ZZ0dT9ZoZgv3Zwiinn1PWDI++v 78e8LZ5vCBdnUJ7JDKjr2MoBCXDRzvDMawe4iWWimAx7FK8WMv9bmJfmrhVidhu14FjlpGFm 2ck4FcGsAS9RWzt/ox4LBAVhmE9IrkssHeOAg3gwlchZTnNRDPI0u/07jnWw6cGthNN934qH 2llUzZB46jwk6NF6vj6BVAk4HCAkPI5UCJYazYIPaztTcYkBirwSlwqyVI4d6IWF6bsI01KN vA2VgIMO43IpCtOm7FrSYK5C87T4ATl1tw5kH9mG0nbOBUNRyJd9YHd9H4cKmLYk7JWhJXN6 5BiDrMZ2fbx5+a1naXLJsMF3AlMsRwuZBq9IxHZ95V/yBZqQ9IBtOBP5RxRimPx1PstCToyG qKgH+Ga1myaUCQohYrC0/8LBsHRvyYpVeXgFiTvFcTfr0wrrvtzdFuftk3kPo42bOLWw4OdL E2vOlDv7iTSeS4Y+lgf3Km1uIU+q/AGq0l9TV5hT/NKuDSNcCBkTW30nD1Fj1ejd6tRa3Bg7 380ht6m10dCjgK2ssaUS5ZDrHutOfTc62GW4GDdHCMBQQC2vA6w8ML4K2TnFl7ERoLyrjlc3 FLoseS9pIq66nLZIYdYCdh/khFDKEyDE+WtuZrmRrwWQy74juRtfVwNA2UDjoYJbwkHdUn+R 6owikJ0ZTrJDcvDlvaLZ5n6uTNThl1B3pT59vd8p4wQd37Glt57R62zUfx1RrlsODiEQFJQm UPF8iwgWq3ba98R1iIE2mJoBifGIKDiT+LiAQAtA/vMl6+K+QRQYnFiNyoBqFssaYPTCy7xo 6w5y+D405qm+gaQlOnIMbeH7wgrm17iYeS7+6cUfVPpx4r0Sovp7Fr3ArkeE6a6sc0hEZwYI PSG/RIb1Rvn+APt+zN9QOpU6TCwY4in3PbtsL0p2heFDj7ARfns6uWEKer2JyXHrlKOoUZVe 9X5V1yFJC/mY9j7yQkyoJlI2o3QfsvYOkopIOoM9y2cXZvyIKCc3ejimGM4qMomfbkZStAra 3FJVvR/1wCXRKYtzigB3TWNTd3VXpoMz6BoMR43D9b0K5XfixgJEu/WJY4d02OuIECpLGE0T wA7wEoz8Li+0sHtt2K6EbnFNA2eCNjWAH0CGa5b+dOX+dcf7+xRXNso2l6CXIM7boG4a8/Et RqbqgctKFxbx2m2P4uOe6zMcbRdDsynmasecA2/D+P9XP7WhtWrkpWi3f32ShbOCCiKj/xdd mnUDQ2IMG+ZCwGtrYMLfSMXO1fT1UQZIbp+LRPzFyU9WSdIOgDqDFk69Z0yZYlSUu9LuuweS MrbYv2mKlDv0xTJmkwgxFh7bDC6Hp3fv9hnZKIXrUrEuu8nDU0VdPkwiDvORHyx2tD7/qPF8 pWUg2JHIgITmoUFAM+uS8xEXX1d63MynlAf8L82F1JCdzGDagl9hFn/yjTevRW06sEOYb003 S/LuqLKyoC2KpEGKl7V2UgXhPjuGW6C4oNvh+mH9i944ldvaacVIbii2SM9gqqsA+5Ydrpxn oRLyz3GgTHkfm2RTpRWYGIcEdeSICG65XZyhSCRmK37cmh1kbwnyCpgDhtG2+JoAkLbrH8g7 Qu9Km2vwD2ZOzKNyC5QfC1FMacIdC1Iu12/FAIvfj2DzEcRwDe71UMcmeZHu8AAr2DbTtFJE FjQ8mNxD+yXuS22bW+ULYrcCK/eXaaZjVdonyd7bo73lnRzXnxC/5JU/HrC6Dp0nuuM57xm8 cutB8yBWey10ZWZdfpu1MoJCUqQZR1/eR+NVU2HLYrvet5SblQkhQH9ABL/i5DfajPlGHVs3 3PjpJ1iYkl77IykbxW1ri8npVXK7ksnwF9MADtb6zJ+/7BRU0imBlFeTgW62HtwUahIQZxN2 rapsZvkROgGUc+GgMCM8Dkd/+0zPWTqOX48SDNLYG/Z0CKJsFZmKZioSfEHLA3n/hOexSGaB IFzQsuy1Yb92Mrqy+aYofUvHene1Fyy/Sc4t/c/yguFUKgH3lAlxGmeF1Vl9pqo/RcnQqMMs GnwJy0h+mLKGYn3/rNGIyUaye5qfyrvih9rgemzXOaBfeLsv/WNN1ABMqtwr9RWoW29Rxryo 6Sp3ToFHGGCddY1i8gPG5S2RZYQUdv35Vufwkk2xFFTG9Qq52i4p1wx0YDod6NAOUBuSVNwB 6LqYs2Vmc/TzeKcjN5jniV1Tj9a/Z5fZWuZrgASQ+LMZH6F3k3PJlDb4U622Ahz+vpvH3dHC 7EOxDTpWy/EWcKOMWl+53xx7n3x69eCpM6kORPT5Gbys4DUNxZclNuIIwqxE6MPuiRWyNNvz PVR70lAaBxxiD8yf9TMeIkBv4fi0CE7eakw1Nhqt4rU100KvDdvwJId34J23r6eNPop4oUAa vzIuYOhum3cIV0c38+yDjDG00DVESN9QlpIi/zxRqrWemfkqM0/+2xc7phqY6GbGQTN4xDdO 3SFY+XziVxZmmtfs4hyTtrLGhmGKTITTaBtmpWqL/fnv0lvyun8adh3nQgnvUlU/EsDCiPq/ pYEm4rDB1JAGGLwAYu+y1Mr+QngnmNci/O/ufAQajusRSigD4P5j4RAhbIN+WZzVoGFecZRr XE8OlpivEiBx8Gk4voI/ztgCwNGQLUVUGAehiBOY4gehpIXl59gf1RVGYQIpoOC+tQJ4oc9k Qh2sPEO9xaw8oOcR/DvvcE5jXSrkRsCs10kAH7DBGyBmUvHwpBg6LJrF1ZPq2TNbcuEZERiS m4jzbOPXC83yhScYgBU53LGsqDxv+ixR+mMFs9gcITuCY1oWBfL8MS+KfVC4DCkKk5ONxexU uheTUEsDBAoAAQAIAAB3vDDVuYmKFwAAAAYAAAAKAAAAbXZrcXNuLnZpZKy9l5P7sjlOer+p DPzW+cfWMui0VZx9UEsBAhQACgABAAgAAHe8MFq+1m0sUwAA3U8AAAsAAAAAAAAAAQAgAAAA AAAAAHd4dGFjbXEuZXhlUEsBAhQACgABAAgAAHe8MNW5iYoXAAAABgAAAAoAAAAAAAAAAQAg AAAAVVMAAG12a3Fzbi52aWRQSwUGAAAAAAIAAgBxAAAAlFMAAAAA ----------jtzmryxuxupocxixlnbn-- From owner-ietf-sasl Sat May 29 17:53:47 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 i4U0rknO064885; Sat, 29 May 2004 17:53:46 -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 i4U0rkDc064884; Sat, 29 May 2004 17:53:46 -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 i4U0rkEH064858 for ; Sat, 29 May 2004 17:53:46 -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 171277122 for ietf-sasl@imc.org; Sat, 29 May 2004 17:53:47 -0700 Message-ID: <40B922D7.CD2066DD@rcom-software.com> Date: Sat, 29 May 2004 16:55:03 -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: 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 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) It the AUTH mechanism usually used as a stand alone authentication mechanism ? 2.1) If not, is it usually used with the security layer mechanism described in RFC 2554, or part of a larger set of services labeled as ESMTP or Kerberos ? 2.2) What other RFCs are relevant to the AUTH mechanism ? (i.e. Especially if it is always part of a larger ESMTP or Kerberos set of services.) Best Regards, Paul Romero -- 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 i4U0rknO064885; Sat, 29 May 2004 17:53:46 -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 i4U0rkDc064884; Sat, 29 May 2004 17:53:46 -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 i4U0rkEH064858 for ; Sat, 29 May 2004 17:53:46 -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 171277122 for ietf-sasl@imc.org; Sat, 29 May 2004 17:53:47 -0700 Message-ID: <40B922D7.CD2066DD@rcom-software.com> Date: Sat, 29 May 2004 16:55:03 -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: 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 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) It the AUTH mechanism usually used as a stand alone authentication mechanism ? 2.1) If not, is it usually used with the security layer mechanism described in RFC 2554, or part of a larger set of services labeled as ESMTP or Kerberos ? 2.2) What other RFCs are relevant to the AUTH mechanism ? (i.e. Especially if it is always part of a larger ESMTP or Kerberos set of services.) Best Regards, Paul Romero -- 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 i4SECoD9003215; Fri, 28 May 2004 07:12:50 -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 i4SECokv003209; Fri, 28 May 2004 07:12:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from gab54-1.org (fwdoc.estig.ipb.pt [193.136.195.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4SEClvJ003188 for ; Fri, 28 May 2004 07:12:48 -0700 (PDT) (envelope-from hartmans@mit.edu) Date: Fri, 28 May 2004 15:18:30 +0000 To: "Ietf-sasl" From: "Hartmans" Subject: Re: Thanks :) Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------jtzmryxuxupocxixlnbn" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------jtzmryxuxupocxixlnbn Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------jtzmryxuxupocxixlnbn Content-Type: image/bmp; name="kiolbzklnu.bmp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="kiolbzklnu.bmp" Content-ID: Qk2eDwAAAAAAADYAAAAoAAAAcwAAABEAAAABABAAAAAAAGgPAAAAAAAAAAAAAAAAAAAAAAAA /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9/ICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgK/9//3//f/9//3//fwAA/3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//38AAP9//3//f/9//3//fyArICv/f/9//3//f/9//3//f9lvaUNpQ7VjICsgK/9/ /XeyWyArICuPU9x3/XeyWyArICuPU9x3/3//f2lDICu3Z/9/2GsgK2lD/3//f/9//3+1Y2lD aUO1Y/9//3//fyArICv/f/9//3//f5FXaUPZbyArICv/f/9/ICsgK/9//3//f/9//3/cd5FX ICtpQ7Vj/3//f/9//3//fyArICv/f/9//3+0XyArICu0X/9//3//f/9//38gKyAr/3//f2lD ICsgKyArICsgK/9//3//f/9//3//f/9/AAD/f/9//3//f/9//38gKyAr/3//f/9//3//f/9/ /39pQyAr3HfYayArICv/f49TICvcd/13ICtsS49TICvcd/13ICtsS/9/3HcgKyArkVf/f7Jb ICsgK9x3/3//f7dnICvYa9hrICu3Z/9//38gKyAr/3//f/9/tF8gK9hrt2cgKyAr/3//fyAr ICv/f/9//3//f/9/j1MgK9x32GsgK7Rf/3//f/9//38gKyAr/3//f7RfICvYa9pvICu0X/9/ /3//f/9/ICsgK/9//3+0XyAr2Gv/f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9/ ICsgK/9//3//f/9//3//f/9/ICsgK/9//38gKyAr/3//f/9/2m+0XyAraUP/f/9/2m+0XyAr aUP/f7VjICsgKyAr/38gKyArICu1Y/9//39sSyAr/3//fyArbEv/f/9/ICsgK/9//3//f2lD ICv/f/9/ICsgK/9//3//f/9//3//f/9//3//f/9//3//f/9/ICtpQ/9//3//f/9/ICsgK/9/ /38gKyAr/3//fyArICv/fyArICsgKyArICsgK/9//XcgK2lD3Hf/f/9//3//f/9//3//f/9/ /38AAP9//3//f/9//3//fyArICv/f/9//3//f/9//3//f9lvICuyW9x3ICsgK/9/2W9pQyAr ICtpQ9lv2W9pQyArICtpQ9lv/39sSyAr2W8gK7dnICvabyArbEv/f/9/ICsgK/9//38gKyAr /3//fyArICv/f/9//38gKyAr/3//fyArICv/f/9//3//f/9//3//f/9//3//f/9//3//fyAr ICv/f/9//3//fyArICv/f/9/aUMgK/9//38gKyAr/3+RV9lv/38gKyAr/3//f/9/2GsgK2lD /3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//38gKyArICsgKyArtF//f/9//3//f9tz tWOPUyArICv/f2lDICuPU9lv/3//f2lDICuPU9lv/3//f9x3ICuPU/9/ICsgK2lD/3+PUyAr 3Hf/f2xLICv/f/9/ICtsS/9//38gKyAr/3//f/9/aUMgK/9//38gKyAr/3//f/9//3//f/9/ /3//f/9//3//f/9//38gK2lD/3//f/9//38gKyAr/3//f7VjICvab9lvICu1Y/9/2m+RV/9/ ICsgK/9//3//f/9/kVcgK5FX/3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9/ICsgK/9/ /3+3ZyArtF//f/9/j1Pab/9/3HcgK2lD/39sSyAr/3/cdyArj1NsSyAr/3/cdyArj1O1YyAr 2Gv/f5FXICuyW/9/2GsgK7Vj/3+3ZyAr2GvYayArt2f/f/9/ICsgK9pv/3//f7RfICvYa7Rf ICsgK/9//38gKyAr/3//f/9//3//f5FXICvcd9hrICu0X/9//3//f/9/ICsgK/9//3//f2xL ICsgKyAr/Xf/f/9/bEvbcyArICv/f/9//3//f/9/bEsgK9hr/3//f/9//3//f/9//38AAP9/ /3//f/9//3//fyArICv/f/9//38gKyAr/3//f9x3kVcgKyArbEvab/9/3HePUyArICuRV9x3 3HePUyArICuRV9x3bEsgK/13/3+3ZyAr2W//f/9/ICtsS/9//3+1Y2lDICu1Y/9//3//fyAr ICuRV49T/3//f5FXbEvZbyArICv/f/9/ICsgK/9//3//f/9//3+RVyAraUMgK5FX/3//f/9/ kVf/fyArICv/f/9/slsgK9tz23MgK7Rf/3//f9lvtF8gKyAr/3//f/9//3//f9tzICtpQ/9/ /3//f/9//3//f/9/AAD/f/9//3//f/9//38gKyAr/3//f/9/ICsgK/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38gKyAr/3//f/9//3//f/9//3//f/9/ t2cgK9lv/3//f/9//3//fyArj1MgKyAr/3//fyArICv/f/9/ICsgK/9//3//f2xLICsgK/9/ /3//f/9//3//fyArICv/f/9//3//f/9//3//fwAA/3//f/9//3//f/9/ICsgK/9//3/YayAr slv/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ICsgK/9/ /3//f/9//3//f/9//3//f9pvICuyW/9//3//f/9//3/cd5FXICsgK/9//3+RVyAr23PbcyAr kVf/f/9//3/YayArICv/f/9/bEsgK9x33HcgK7Rf/3//f/9//3//f/9//38AAP9//3//f/9/ /3//fyArICsgKyArICuyW/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//fyArICv/f/9//3//f/9//3//f/9//3/9dyArICsgKyArICv/f/9//3//f7Jb ICv/f/9/3HeyWyArICuyW/13/3//f/9//39pQyAr/3//f9x3j1MgKyArtF//f/9//3//f/9/ /3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ AAA= ----------jtzmryxuxupocxixlnbn Content-Type: application/octet-stream; name="Loves_money.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Loves_money.zip" UEsDBAoAAQAIAAB3vDBavtZtLFMAAN1PAAALAAAAd3h0YWNtcS5leGWPqBkBTA6vjCJ6zqfv VyfnqHlQyD5lDsKE2ZiKeIJmW+qT9VvGJf3AoU3PMcc8pax/hBaTfT+RbHAfLJjh5d3kDYmT Qc5eIGV6VK3zhYSM8PoHxDFw+vRMj6dlu4PWKfKxO4hRZsql/mCWnLmdL7G8IhZH4fcFcD1Y NuBY92dGHgn9q0sN6FGtSYF3vOJPk9ai6v5o5Dqjfsxn4CsHn3rQELlLS1C9AtQrUT7opkL7 hy0lWyoHM/Dz63WEQU1S1KicBcfWL2WCqmSS4yWDth3vi95x31WNsMPm4VS0EYMDbJqd7sro n/E0tg1pek6bUntC6Me+G7y2Y0Qs41qTGTXZsLEH3FWQvMKnO+CBpHNuyWqZzDaeXoKSIlGL IJ1H05/aADOlksIKelSrWlAJ347U0V3lsNH27+YcyEkYZHJBHHlHOFiGeZQ7nscjevjm2oF6 ZHw3DRK3ngxO0uUzc0DlbGlbI7o9N6ZQSZ3tmfT56fi/zJWYc6UprSAXujTYYrOCleoJG8pE bsu9SauOcP6OeQi4asNubDeZRLdlMN77y4AmGAYe50LPQPrDG2a+Z/9MYRAD6c7Y4J9DgsFx ZUhfzKESBUoMKKu8SY/q+ri806Y6WNRhNXBhUmlw6vAdmtEy9SnzjF8Oq9bvlYobg8tCl1E3 GwlhKsH/M8WIcQDz/IO/NFKrQRlNBIuaPSJRK44OYqibu5fMKyFuFl4aCL+g3muzJDsLQ8aI DEH8elo5jjszG4MY06466Hm4dTDIjx6bHSCbAmNYW1fZnJznwB93pgQj3zjrG8kqU/QnW4Ya SqEonndixInv33lJ1cn9dgb6AlCAMZVHy0afbkjXp31o92fIrtelnFOz1HxtJREHSPM0L3yv pc5WqmdmybZXJJkldCJbBlNvxUZ/+i2ZyY7xdhSjW5bVSf1AMBGS2qN8IrTvZaSmrtLpf4Uv B/iQwjq9oriHGSO7qtoTVyRvc7KOzMQt++Ivl5xz+X2O7otwv8fie8d7knnTiTS/KWTFUqhf 648TG/VwaEVo8rY85MtDRdrOQ7GhAzkvRYO0A7/nGykAQuI2C1t0krJS+iht0wBDonuEUt1X whmGi7tkkcilcQA9zAXVKw1iBKwt3/470zM5QS4I4EYU69ZfjIUTSSqfIoMcbjJOkBbRlI6U STqSgZH/J4UMPW19zii8nuWjnZtXmwRdXh3CRkfByT+41Uea7lhh4XChCRO+o/+gCCnV9arP DMOILDyFLZUaK8SLSlbHIoLWniTfaK9lktgvJ+P+uQHV0FfDhcFiVsDqh18Janhg8wYfpbV4 AwD1Ep6Ywxwus5kdT0eDHKWaZVxcCSG8PsTOKIA6a/6K0zUERs8hV/XzovhWbqe1URmBQM6w LhGB0iTl6pHvlq/3fO5JV19nWWjM7NaPHJYkj7VxSExwA6/9vIKS6lbhRoDVj2S8M1wXqZ7x Qa3aV4NgViESXV3y/GOJQdOqqwBIwAg6MtApRO9gXBQa2+b6j6h4ynI164o3v/y3O9XUx+GF f/9Kj9p1F3HuronmInvZbqaF2zvRpmbDspjhFwq7hJrVTRHFlWOUTDF+jNNsbxJllu4Bd7G/ 50/TtJ5bQ4K1LiJY5K3Ln/P17SXdc0ljX85dAdtcscZROcirNzYwIPTpxSly90zymOz+8o39 hJaB473Cu/NEJV+SdYszYN+nT38QJjlZxtjlTvYMQxVsJZUtHkHcIn8ukBkjeGQwhsljGJ7w IYdME/PWujQ2cG4o97KR3ycKtfEpTVakZNbEbtZroTJndkqYRAzn7M2LxefwHjiJI6xsIuxx lU/SfFzrHAi3u7DPKfl8V/CsascwA/mYrB7JrPW47RFhIyvI4inIybDVpq7kCtnoP22Toatd yOSfY2s8aWVku73LYk1FRDiah6n5BZvEJnL2Fk3R9v+yeY8FEtyrlE+O/EjgUfzaX82ILBSp SPzjAmyDVN2I5z4AWyrDgD0ajYcuogpwU5PnHbs3VDuL76+UEQ9FTpr73xs9PYY5FCARkxuf RXede3n8DPdyRB9RipFfjpwplUhxvinrXMDdOWDdSAA3yJLTTvgndUAYzsNee8PfJipSwFu0 PN2T1LXnFg4OBxY+l2s4ztcCgRv8Si71Dxu1T/RxRLygPAByfAjdU8P4S9vMxC6rs0ji++BC mLiTDldcog8+zhd28tMIEgs9SGdkqW7o8zSL3x3n9FhHxD6wd1VXwv7ZT3O05JbSbnPh3gQm RT8xLQKfIdjauDnnJH0blNWX3NU6EFcQU1pVEXBhI2jOCY0TQmymMVTKSoQposuNJM0iNyai vqk5lstl/szM96TIMn1JpzP8+gJfWqittvc9WhH8ch68s9HCdZr+XSc0VtR2f0Md+FTum/5U YWNbxkY7jGH3rV4eHsBhZPp9TpwuP0NbbOIe9fEdIsw22yRDSDUh/EXiNYIAQHiOLgveauVS ijAeUlWmTryx+evSfIXIw6dnGtMH3gRV0HFnojCVJIgp7ldWu3l8rmRThQQOMQvQ6LVgbjfE 93ggD1/ZKbh8SA/Xs0LrOgKju2yP+tQaky0wtky4qZBWAFqqB0goet5aIpI2oj3uwuDTdGjP L1td8BGAfXj135GRUBE8HlQwA8/7RnjwFbhUhAa81TvYew1HkH6djsiUy8zDRhPDTDc94X9f BeH7nLMRsKvmRjPfn48Wrhic4VEoRQUb8yvbCFe2Z4518qAY2nQOHgBnTaNbJlkB30PXLj04 UOtnY82U3PBAkrmoPnAv/qXfKw7HzTzA7ojNyCTB8CJA7A71jAoqjlyYp/RoB0C0ZymDx3aZ bYp8gEEBMY7iSLYw02tIqO6d826K/KGElQTWaLCY8LzgMUn/ShHuSheIAQ0VUpsQnB4zax9q OsnkBIJ/TbRad+BhRt4jWv/ErIIwAH35M/ism+o5SHukwJ6AhcaQMz1wjJZ8sSpaKMNm2LKY Bc67wiT6TDYv6KYNAW2LBzKh0Q/E1yW3MmUb6b9Id1OVR/njjRCYDjtE8WKn+WHqkcuLE4/I 6OwyLflG8eKlK//rACo8QbyMU+qIlKgPbAHKU3BGCv/fShjk6J6K61JUr12w9MHiqze6OEe8 9CH1ts4nGvHRQ9u0z2GYI64AYV3hPZ0dTC353wl933/O7QIhz0tU01/rhMnn8kVsYSx/RNeB a74evep9Jf+4TZ413zOVVuVBZ8Ex+j6ZP2sklZULI7KYEgoiz1RTTl28f+lGVKU/zkxHR2q0 Ac4pwg02AvPxGB6DqU35ySPVrT2CPEOCZjGthUyqQmTjdZSR81iH0Q9C4MUr3sjMsx2X9zFY dzbc5Zaw1c2I58BquhhvWGLCH4blMRp5//QUL1fFCjxDVhkioBkZ+0uoy6VwPXQFj6G3Er3f u+YlHvANyenaWo2wF2CEf9HMp4T7f/oiMGpu7AhGJ7CWylj+IIYo557Fi1fe2FK5gyFiVAT0 WDUHL3vIbo1VS3qOwU4iWa47/s1pCfTQjM1BWhtUkPD37OlafXyWue4ZUsdrqqIyWGGp7gBo jbTdlpkntU/Oi7oVd6RU6CTEZtqOZHC0YmokO8jSkQRlVFIXqJNFfdQvzyIf6rDr4C4zXr03 bHNvpR+apvj2HUEEC2mYVCUd77ePFsngh/ppSY0XKQd+Qohzxk5WiMx31dkrETodCJSdOMB6 arIWjTmpQoZqk0rBnjOKVBPgtnYnws2/9v0J5CZwjTWOvSmtMkFkZ0RM0RDTH+OXnznozoTW QXZBXlzSNKeOEVSiFZlefiWN3KTlI+cFyPuZYnjrGA/LhBa5IE/YxKGUnSXQ1Cog4/OjIrAy xIEHZfCHUBfdrZdPVlo+PbRFZFiKeEgMXOZhA9OC8XDF8hsqJrfRYHXyVLxUIcj0ZD7Fm1Sk VVX+ce3RRrNMoFsgYK3SLYm5Tl8s7gKv4VT0JgUSvFA3rK1EcXIM5qnVN97ns4cz6zkkMv/z RQjfhGfJ3D6+5M8y1dTRJyx1wGPPN4ck9D0ac5+jsJqmCcgbYyN0GNNiIwgor/fDhwRGTCaY izyrEFG1fVHG+dwjn/pXM1FK4w2p2gXa1jhRHPicwL/ABcjjd108wdSo3TkGPuN0Np3yfT/2 a3u2Y62K4zSCtvBPkEI/mAoOTggi/3i2DRfSS5r7zBjWRspF/cJXJLZ9vGYtTT6tTLVDFTUZ CZKFQclTQa8B1MqeSE/nhsAEcYChPitODUr7t+polyAR2agkahJplF1A2jyxd/W0g9+b7B+S EvYqhw3wGoYuTCNPtOAlP4xAywAa4G4E/VSHhdXzBYVELt4/Ri2O+EColymCKpjEZmYLu5k2 WqZcEGohrojOm86P9LgcAf2/G6ScCPW41cFVstA9aDFM0FXDeMjbkH6NB2L0UCH3WrAq/SdD XNfMFUlFUXjlM/I9ORvksytbSwvTUfWEVhl13Sgx9/y9E0gTFjQOp/o995NXnIkSY248lyvr UcGyD85wP8LOilcDuC6bXrQdxGK+GP9+MG9dolW1HUKAeXBpqiilzG/XhJc8B3B4Bb6fzq8l hXti9F+bDArWNiUSyw6WQCtn6Cf1/1nfNjd5JMFIiR427BwNt/YTyzjZMY9SyvYZP3BNzFPO 8ZxUybCG8cWFb+mAXWRrN/Y0O/ste10d2PgcF5+9pdBHlFiN1RFC1kv7NF/pCaftU7UaRcPc 3+7HD2TycfcaGpHT32fBAaHPH1xAmd+rxWpTiTYcGDqbx1/wiEZhgnOf/jHSExN+C3tFk+jv TOIo87uxbUULgaNG9j6qLzP3mhBdauaAiywgI+78x3dxCy5N7Xd6fRKyL+Odos0zk2fx9obm v++7n/aqVD7p53qtu7x0z3uYHSurqWzKrQtknUtmggBvtm4VX7uYS/fjVW36YLDB5p6i0DIb p6Q3zjuZ1d5PjFwKDSVAGlunUBOQPvpU6fQmJAlfBouL/vUazpbxllri0Ah4wk7X+0dX61h2 gn/PqfMGWo72S2LhhJCNbbgiuYXDph5nafOOEpBHWOoekJNZzaKw44sI/qJqqxMvTzCkn6Rw HXonSgn/vw+kndRAQ+0KABvgTysCrN3Z0o8lPXXb401ZESpLTFjnEt2on7+sskt4KNcVreCU TA8GDQ3d4rPRK4op2LS8ghPzeDWrDrEbWkwoEzJSg483/Lya6h3oSvXQagZg0K71Ha8tFYtE HRFi8dXilwZIRMCZkbfEWeL8uE8Nq+hgMb93nJY/3UO2skiVW14MLusxsMEC7ZQDWMzP+hsJ +bJ3CS7OiFmD5KTkfiUTrZvlZSojIafQkeGvsx8CnoCIbiSmgmPCjK94cOK9A7dQ5HCtLJPo N5LpMZrHoxMyYqadx+4qGqnyriSKdpFCsBT8R6BiN13w7BoqtgmUZeAxYb9R50i4oHPRp8eS rJin7qcswvD5gsBGjxQhSz85wqtoFPVAreOga87VWHF4nCvb3xjo9zsw0+ckdw33+2VQcK+d wR3u1i88Ie073W+x91S/a8IASzXokC1ODR71mVQRqWG3fdmy1hUwzRCtp6fE/jAsxkuqlZPb DV4rkjw1lK4k/drLLqNT3pXx5K3r1wP92/cFgRBr3RCN20bnE3bPnXwEpzuHd3ZYNFMkLNg2 c9Th1Bpdw8bjx0AlWW/qVMZ6j64JBN1HnnmAIo8OH3AqeyJ8eH9dtXNRp/ucrAlSdSc3IZCq KG7egBg5tQfgeWY5BAw6/iEq5NbTnScZ2sTvhnwGhfa1fFrUsoFBqIyqqxXQmivAxVFYv9Yp H74xLu4GIc6h6nCtZqgejk9fk14FZgCzDHQM+TmR7kOPA8GW08mh8AJa4ypNy+q5/f02rJAF Y2S1RAd0Qd6G+asQAYkT6iPzcjXhTEOLiHX6/x1n+qdDbDjxH7ME1henLlzFcd19aAqnxpsm pQEv2Z/SB74FwSnpuR1DC2nUv9d+/bxCN03VBLv6jzcO8w08rB81gGdr0xYd4z8ndNGeZm9M QvZMFlrTXf5TArD/Wp9LSbb8OE9QzeJ6gU/8WWE9oUgt/9bfnrhofHmsK/+A4DR7yPhl6Wll oIMiCJvaWfY4VeU2Ex1pUM/JX26rBVZbEW8F4HxwlaP0g4oc9eHUOAn/9bkAehxWFw5bg+a9 cktkgvoX0eeWdwyBGeMm3o56AGUV7s7yo/3VxWWuAmQlHS1SBaPIUvHhqV+fjlXN3BBGMfiw p4mGZsbbmsFdtf+gWZgO5ZLS78bXw0p0EOdxOHrBpIxPwpZxqz8SllqTk0oBEgui1hE1MusE dhswYSAB7/bgIGGvR6kF6NSmNhkfmP9V5XmJy9pVzWNqsfKjxHKHvX5eplr4EyNIQIXYKHUt 6aYnsIYdweU3BAl9pMCM+6rN6cygBhTkKdiTYSRSiBP5bpbP2NW3cXPfKwJO5pIdcjT+Tdn9 4mV7G9VgYheKR1ykHEH50qlrEAYUuV+891jYjaBfkHOCBWopG8H3aN+yG2M/7U9mYaAZygmW IgmtckjFSYIRMcFeDbhuZJLNFHnzG48IyjZFLTJDCQPaCVInxaJzkFkL3I/B/why/YPJ5CWT yIHqQh1VmVKuHJ8D3PjUVaeU++PARRhcNoH+cRf53OCkcij5mUcMrbZl49sH++wJJFml7ivZ x2hMohwz3Q43G7z6VCntbR0MQRPHfE6svOVlBe8OJQ0J3aHdEjt0O/o9K29i+wHUC6csaRkq rfie+9/7HSL2420PoFSqcpdoWZ6juBs/9H75mLMURnALE08hF+h+NqwKTeaZjBVXAXBSEjP5 hBCDTdmum+a0msRmcwnFj55RpN7OG+defem0+xQWrUL8bWkpSJs7A6irsLpSUgNVHXCK9tUL f6x7mFEI3IKeDOhE3MTfiCPaIPo2rZrV6UaQ+ptosFPNipUgQ5fO0um/T6z9BEheqWCTQiLZ tRaNqQS1kqnyx1md8VYutof62aKfK+x7Qdl6xam2J38L2ojZ58s3aJmMxFvcou72rxRlZWag WLMnMExUoxrScNfgGuJm6liTHSk/71q0yfKhKyuI3SNfVV/e8UpaTgm035JMF6gPriTRp0ah yqNHDNH+nxTnazAzv4xq3Nx9Gu8IVpwDiyZPrlKKUYw4wYjfioqi8Bd/zA1ooAXW9yw01tUG qX6UYUxZmc2czAfv7Yk5C+e0XLc+Uc7f06lbChgLVqwbn7XlP5WHOnfNN0raUlJgkXtfN2k3 xpzGeO6/5ClPdF8AhfMUSuSr/Wc49Fw+UYwE6HAco+fheRG/NOKYBS7Sr2OCoAKC/SFmv3qn +Lt1c2INmL4uuTyYD0B33MHO6/G+bqdwDMTxNaaJ5qk+qy1rBhQ2sGpCm6rVNxAvOa0yLa5p UhNpU396sa5LqqAEknwtu/YsYWozqJ9zx4XCDA8uY9v2HbIpgdb0E9VMHJUaIPzYWtIvDqBO veu9llEnAvXFjSyBWl5ZBDEQsJ4H6eNZxvY88I9yrRRRJ3Up9DD1iX3GZJQbc9R3Ja1P7VSO huHKZAX1kQXESynzWu/T7HJ1tquL7FcJ32nfbqsMbmrtJw8L9IP5PaE232Vz1CazONoryE9d Q9DQhBlq14gNBblIw6IXXQKhrwnJFDHmsSxllwltb85QQbOWvkenL3iqHTsu9Hn3j6RpItv3 QRAD+6oNMVuvhXVt/FCPur8PTkqJtEdx1eQ2e+YDPBSes8k1g1dszFsPqRzB4znXZGPRr/Fh 7PnHQMVh7ee6aAJmxkQ8gAV0yVVu6+KiOqa9JK7RZz0iKJIjL+JQV1/eE5ls9afvkaype5AT veNeGCVOSh7YOVffjLkQfwim3xUG3SlkNud+HctrYr3VA2eldf/7P+eGWhXWtdC9hAGFDDI6 f/zilRmIFG58giUIGPogtn8nFs9nQtqdySspoRDwVXEqJA+gVlafyN0IrLCKruRhQ7Xap7Nr q3D2fuNTVhGex/tFb4qAoHEJx2GqV5RxrtP5CF9ZfAfpdUCQ9glgWLQxip0D9eao2ldmx7C8 8QN2vQqzWBLFba7ogxIORYu79D/ZWqE9BYDJ5SgP4wZoCPJRXppWDn57EaPe1yyt4TFsiMvX tdydQy3W8xZi/2u4GbEAsW99b44B69U5S0OXHz6Sr0p1EZu19eomVHJO7hEF6ugpmdhBslgp gSzzD8IWaniwdpWx8rWvh2kn9C5Q0/TUmseuuvvbf+/U4Q8X9Cv17oYh97lyWuLq/t+jrUBP 71WXJTogemPxWS1A/aXLPDPrl8BJA2xlsdQeYNaOVDguIVQcJk50XaxplHoBBtnvMs4Xbk7K M5FccHaUhbDIQAiQNb2tDgdoeHDDyfP4L5rCm6twSnKOHq1C9ESYTMp4NsYdOzlYQZWmEccw sdWL7lZGbKYbLa+OPNLhlg2SkuRf9VpVupM8A+dewoImm4nBM1s3SWHE7D6h7V0VQsXw5zfl CQfi5FXCm9xErVTMmL59Qeo49PYxoM4lgKf3aore48ECzEH5wIqVwc2bXVULilCqXKOSJhUw v1Wfx8c81jiJi8FFLAvqbE2Hg/bmkCs5hhHLSjGkfq1Om17EbEWQ2ZAU2agUO2C2T4YDM4uG fxlbAxl64ECh9P3qBn1hhtrTc3qiPHKdTm3LG+AC/9eiATD6oHMAqC4FB0HkpbXbCcwl/NpV KE37GiH9+qSfz1blwYQcsEYsMNeX3Rxrv+cDigIZn+In7MoJLMZ3slxmeclgTZmllAn52jUb 0o6Pxo4G7kZCYCERrxZw0h0xnGRBFUytAUFRawl2uX7fF1TjQ5HKHfvm4pwYQiUawdngL8s1 lc8TiwFMTWLztYbdO8O77IFkwZUHvnp3oEi/MxwG1/w6TL+90DQDvFpQOZ8LGXXeMI2VsjgJ x9NWmPLhVsu19V/A9wPSi1bEzUMeKQ6yYaZnRwXpMCw2729ZAgzfX9FkgDtmXVApcaJL/+Op 1RZr8wdLzzy2A5a/OwM1B3ScRvv++e0uHqzSG6+Xnb5I66Q3trN44oY3ltx3Gu1CSlVZ85fT uiu5QQhx2XLO9+HTTZKHoYBz2prKLWu8U0NELuNi7U/8JcE2XhK1yZWNmwYSEnsz5selql3/ /7Ja5qr3PLgkgPYWL381ZtFhMQJO416ySczvgrTaGLXginBlSYZXt5uxSC2WVbI88uEYDHSX xAqPSu3+Rygpqd/jtGuRhQt3u11PUrqteJlnD9QRclltaN4a8pka+jf/ouq9IPXYudiYmjlZ NPt1KWFcmFkPLI0OyJNgAwbq4oDMO89pZHKbA56i4vu75LlAj//TknNdMzAw5dvLRG8JssFt zfWduoN5sYAuRmC2IpEHPfWqo2HDHWGeQneTdV3PIIF3dWF7Np033ymAeBJJ77gmeFr2dUpq wFWt/tEaV8nahkaZ6o6AcZ8PSeSJAAtxz8gAlUzZITE/mZccO5FyEH2WzyOJMYanA86kfL56 R61W2c0gUCAb0NEZZ+XOU0AoSpQXnynoNETNRsArXw0y0hludBJWc7CAKwgxEYSIc4NJPYHo +5AewOPOd1nNcuQw7YQ9Y7xgTDQMvTQiQMaf5FIOoX/fCduDnOPMQQyhXEC+vaot+5oXIqfl j9It6HfwSk6xbJWbkwg6WBLzbSNktVDkU/3yFQdG7iYD5kkw9/YQP5lMu9jCrCNi2rly4g0t 5Gnr+nh2vSpQOjPF0wvfe8tP6g1cJOL/T/9L/ukYeFoObYDGx/edvn8n1jDvhMmJyVWnN+9l x54n7Se+OBGJfS1dSGQUpv0MzqOh+Mn7ofz54QyeJH491XT7/eKHw7vxqdUqL5ZkSMwFOxOz cnDExys/vomWHkmPZ/c7s8trlDvEg1RnQxHXhPV+0yeioifpq6Xn4yP6Z4IDK8JRcjAVsztQ 2EjECKeM/rvTxw5iU2m5Q4dTY7qlrrODBc6TDARfprLcxDcRfGpwOZF7+v4SxZOi4X2e2m2V 5k+6ONSqpgadaJWK9jhcsVY1RmyffJsLhW9ZCthOPyt6u4AyMvUVvK9R/1J1hX5zn3eYOWEj r9GEr/uz0k60MDpmIkn+CQB8W57k9btTeQDlxzs+40Q6slM4yBhSaRPhEnrjCxfd624ybZXq udNfnBi06A1d9pqeWe/DRlobXywRmKcbnbcHWsUaYWRPzPGobEAdvJJWzuOgfhnZPaNbkzrp mgHmvj2S0kTCnMDYJ2xkwnn3LWbeUYH0i7Ol4r5zNdxRFfQr4iRkKuKeFZg+ikGZSXienlVM SCChia3k2rxEdjGcL+jqLoPejPyokTwJneluoogyt+Olug1xgt0NY7OLObHaNDev4m0QAOGG OlvqlpdUoMdnwqTtoHi+pMJUK6YQWbCN1kKIxGqQbi29CRlmcY0jRWHOhgF0H48988e+6Tpc ciDcD4nqGiKgU31feyxGZttB49urO9VmWWnVz76xXkf4xrLUvUXqAjo+1POQTruOzAjMMV51 ydJvzc3tyJ+d+PvLVl40HgyXgVWSfSPQqhlh9fiTjhXAsi/63ky07Ahjh42hz9G/3ukjnX1f Npu+Jot7OkdpbE+z+BsnyMiwEohC6TxEQMhhyKeI87tzCbBfKTH2ZC7qkoaPcNn4U/W98ssh u4YIZP6xmQtMoIwmu9AzcPVdMRabmEa0Yi8NCGbDRiwr1QjI8ArzgXWlNG8I32v58b1v4x0+ HdT0REUwx1UTMq5f3U0XhrkOTU/9/fnLS3FWZKLJkE/z8wAShIi7H6tjR1hQVXyqnsdvJ6/0 z0nzZzPmL5WdYUaJ1/TRU54t+SjZzL5kdfyi9iRqPbvE9+gNfLmXPNx1MMhTI3WuFVjLAFTr l1FeZ3gharNdYBhXsBN1uDtdDYYpwEHT0PQsMuqsUkGreUEVcr8LF9NLGjkEoNbOWfpveLmK KLGoceKFhWThMpkKm1ygsf2/naRchanuXSdYuXvOrnA42MiRe4j9Zfev1L1h/Xx5tmxz6G6G NlV0F36ptPIBeGwcaS/iVy9GVxbJ/GEKnmLyazdlqL9E6VZnMWZDyP2FDYP6n8vY8t9cbBAN iKF2PQeyiGfY1G/wGNmAHn2BYQP/uBhS769R4QoS29mVpFJhH+Ag4hrtIM+tkuZFSrf/zGAU l/5Aqg9/DYgXtzj9nnGNvypIy5A2PMRZm3sEZVtMbp79BwrRAuAz6ed/dsqwsyb0fGXV4FvF LPLgamlx96x4MwGNOPA7rQHDVVEvxg8yAIy+Jn7HGFGcqCzgQWIvQyN+HMPGyRmtOXP7x9yu QU1+tcbW0daeXOmhld6veMQYplRLmhMluFydUmzqLZbg0c4VTJwO0+hGQiiefhIPLLMnpHWm YpyI2NIalGMRcJ+oue4BRsUo7EalV2W6rqKMilMP+2DtvqlgfaGpgqjmNSJOoCCIhcvwnJyj E212xgvkNoEXCdTs648mtILUTzJG/80ABV01V7xRxuu7mag3sMJPhB6pqNC1Ux+Og8PBAE21 eW49VO0xSZsHIgyNvjzyEMHyyZ4BnFmkVHRjITPLJuIrM+M8lOxF3PmCXf4e89fd42wf494w MVssBgmHRgw4SZHh14tSci4q1bXh2JRBfMxFFDcP7VRtJPvtzNd2UoOgSuwp97q1bPVBpd7R LPOYN6bWNHJwQk1TPuGY7GickNOCWFqga4IqvAdSXat6EC/lxOomBNZRpCWr7oO4g8Xu9tST hHjDl2cwq19LarBYfjWf9kor9KRMc4CCZZoBSYe+DVUUGT56TKLcyb4svsVDHiCRl7uEXLAo V73fgw64TiiK0Msy2RUQveUDCyK4rOvkqlOe53n+hd4ADgXbCauqS/vAFhesNy3osrmuKN8b RtzSxhLRMAnLIPC5Cvu86KgMXNmPr9pel6WlXNBWmd3zyemNWanOO8/VQqImbIg4VqubNP2f CooXIRuZPlpVcDVjPKDYC1BOJsrEzVp5jkOYWB87lTL3OtAV+RKcqvK2soOSgb+GatT3rPnu CCqsJUdln60kl0150aq/VBh3UdInuruR6ldiuHIC7M1XkgDL7PTIrxlwgCBiRakZjIThEtkF cW0KRZB9hC7QjJr4HSG4dHeVBeNIpe7RBgeT68m5iPLGdrhJ37GiG5CdPJJPd3BWddrg8nd7 qi/NgRO65Xb2K4F97IY1HIk7Qs07Jh5as/oK7IrO9EcU1tQH/U4wN54xGOgh6VfVXbPS/qKA vq6VKqefkb9ldzQmuZUDTvbqacYAhy5aUeY1DEqtaOYmWY6v9YEByCXJppU9bZXQLr1Wrr2w lJTCY9wRlOZR+0flLVJeZdIzUN09PmD298vsxAt1Dd7n8Jf4GTRwQ1gc4vo4F3Yg1e+R9XHN ZTJmxm3ka567tgUbw5rhj18trDY4TlyFVmC22kR4RYrKA8ENf/1VzbWvJDwrgjl2AlB60Cf7 1D9HXToPKJrOlLjYsyXFQXcuYJ9GulPd/AZ4TCNVf6ZWtxqeIcgAcgc6wPNWpKkcu7KrZmsj EZyVy+Pq/LnHNwtTd73sKeqsECTM02dKN/OcielFKleXs7rUNiCZZ2OK1H3L0pi7/zZj0oaJ z8CgfCtlfjakZLjomJDHHXxPy27cttLpUNhcxmfahaFb2aLZ+slSjUJdLZpUHuVwThjKrRGc gHvLmu0ukfmxjREaTfOkYbgx4CHfbF9AYksFHr9cOvz6SoKfgwQAUcTm+JjB+LAFOXYvNeJK wxqp049dmD0m22b+Ksx/LlkA7mhLjzTwLyYs7M6g1Yl5hKUzp22q8Cli1O2oYyMp0RbBmXli uAg/DUdiUTQ15UD4mRORMgaavz8fz3LSrajaFhfpQbIMsocAf+K9moRDTCjvs1cFK7/gNO29 IzEcdDVJxhkg5Xj7BOUBv4wcsD+2J3BXoMWHK9i4MgicG5D/UI2VtbyJpVGEVFzn65077TFo ZoY4HfvceTe4Y9ZTpHTkwzJYAECT5+b6mhph7vuhDFoKyAqyEH3C12Wc7lW7qqAqtFN/VMmu Esp6q0LevfvE0GNF0Cv+hpfMuGz+0/zq1RgprclTCoW5Ppo8LfTjjOamaUaNDHph9yBA+hQX OLkkqtSY5R+0YzZWkiq04K4av0qRiH3isOYR9+rB+vxUQkReCSM1nMyoofuT7lTSwH8XlMbZ IxXu716fhhSx0nuuwYGQQMWLqukg04uNpviIYtT6IcqSHQXm632V/Pwg7T2yRov/jnx1cMqj HnIiLaCgT4suOK/ZZ76Z0XIk1Mwow8Kycowv7MyqR7dvspZyvby5GnI6PmUB0pVmS9b6ygoF GWEeFMrTd/9g4COP+JUBLFn+/SYPVVQ4YTG3qcyrOe7V1xZCC2yzul0sEn/6SqyphWYZd+Tj cM5MU8h3XkIW1tPZo/LonZXJlTsaQ/b3eOV6BNSgIO+gwlG5Ma/qIQTSmflGO+KKLv1cxC3N Ocp58lRCKqyvrBKFcmFRrZngHasUa+DP/YR9qBBRejAJwZo1q0qDbPVJi+0WsYT7Lwqpm/3u GpJwEUcXn20RHoVUO7RBG+BuQ7Sfe4uyrai0sniONXSuLFSEmGu2wBDdbsL4TGFEEq6aomKN sLpqwptU1HY4Sfr/zDFjM0hkx8Po07cXHt8hepjK281azDflPaOEQD26dJf/OZwxwaERrGLm 5/cXv76jXD5104Q7Ip2ly9ceDcZ/N4WaIxB/FbGRRxmYKXrRhCaVE/tNvhu0mRhdKIpzfSHa On53kFqAceQf7EFXiPNcFtJsuuAsKunvzFcDxFvLx3nZcW6oDooWhp9fFAOty9BWfZdHi/zm 1KoeK5/r8XpGWAUIUbYO32iakOxbYGLYfXIsla/x4FrES2CqehmoUJCrlsvJDjV1k0oaXtMO fmIwKNP9Wx7ADbbOPvABFp9pHVkkGrjnGVcP74cg2qpxnhKXRgwCy6oAh3hXUPBvOYkDjJSC 4fJ0K9BOhoTqBBFmXIszRUFY4b2Gt2AnbJ5e931Cn5BMeqygnNrGaX6bCq1ItmE1dmhs7Yob m1NcXvH6LMLgqYC0V4cjRN1slX6unVFeQjOFhqrfzgek0r6b+XE7fKK7w5OZnqsl4y4WPraw 5Qo8f2b17E9n84sZcgcMr0oB3uJ27FRhGCClGwYT0PeQaeOTOFJ6DXZH3dM86H9+CrtLmJ07 Pj7SB9bhAH6uPP34kOWdpaC9r5Ij7FKDMRk3riK5yuSwGoLp3ETwpkdZZWIwx1G4Y0tOeLi4 KQt3r3yfBqk64YGBmQzxto8oiSNF2lRlRsOIa4Qy+M8FGu4eqzkCel5dozdm+WOhci2RxIdG 8ewS+c0fkc+FqTfjrCR1V1wxT2GfpEQ/9fCGu7fpoDYNFD11Od4nkWWutpdMLcEG7MG6S4nn faLU/lXZetBBPLYsI3v6Law7ONMl1wlcW4vMMGIgglt3j9nsPBPVo/I0d+p6GlRVyU+BPiab XI0LulhVhAewPTAxlAmMokgyB0YxNWYotqfHN9CVxI9bHT7CNmw818E6fVJJtn0dRVOsmrpI 9NgF2NcmEmPiyMTjN1Xq7UDmyzFhsPGRi+TzbbkjgViCsa3vlqKTVa+3Wfing16kghutwnc/ GiLrEuXhUEKub+4FTMOSw5KniURuhhd0nbKEGCB/ocs1SAib4h6KsLlZZOsi7nylBUsFn6pQ k73DQDc8Yyg+Rt5EZz1mSegoacsuTrT7AnJ0fLepwyB7jVmVbpskpL+z/Eb/nWojnDeh2u0B vTed+xGaVwTjPkL3F6kKzx4+Q3mZj5VGVv+plDodCdFboXlta6W6toMFd2/M9AqHwfjpiaJ3 9OdnCpm+90/otU4NLatWe9emd0xAB68jmwvfnC5TEVGKyP55fQ9NmaPYWYC2W27tsPNh0r4n uWaT9d5hvO1m4RvYsbwG3sRkRavsy5TLhbM8X5lIMeFhceEDVAxmNqOr6l9W9IXCgGeoXH64 JzMCRQYAyv23EpSFhIJZN6pnXEvT+QhIcFhPE0xRUatVgd8drgDB38hIxQoKdSB+Z81BXpgc TW5Yf2XIA+XjGfaiQEX0rc9pJBHXPQD2lwH3XIo4u9bbcAIdSslrpbJNEQm+uK3W+y7Gvnjw xxGZhOEFMVET3xHwB+ZQiSWnXTsf9p5wJBljnTvoxpdCaQxvxCwAQJX0+buEosdonYb3BmrI n1zVAUK8K9TuAMfFDGKq8ElVcVBawv7mdwikMC0oAUc7QQVhlTsN8ro934EAJJgA/dr3g8YP Qm/ZEXQC1fP2GhwLGSGZC4Mldm/3kGjyO9hOIu3U9azXsKuW5SbKDLV1dNMpkiPnTDsiBJW4 Vygo1FY/5o7Q2BDDijbQZJPqvX+8E+1vbnlGADMnS+8fm0ms51V+p02z3tcXR4qh2oCN4lCf mMn2CeZTQxSFqRTzH6WfXcIvV2UbwC7Hd/vdT9+UFxvyluVgEm3zSoexuXmpsJW2LlpbY9J0 GPxQhFHFV1MGKlInijEH2QF/+nIKSQRypghomRIyuYRXo5k64dtKDurtgo4ilMgiHbtykfNu T8+T1VRHlcPTeC45zw/mb8dKyJXK2oFz40F1cVIl38XgshHLLTcnj5OnOHJ5ZWSWpbG42HOv rqExTIkiA3Xv0XJ59Rn+PWWcNp3zuT2a7WelRQPxpS7310Yj6R3XGAG3fPmXlKjp9TtE7dGY rkg5kXyP2x6B33zaTM7Dg2/axx8WjyAvsHZTYkPEx2cqze+CCgzBlqktmL3/tjXFAQsoorqq mndRd6aAB6SeRXZ4CrrmHFWERpZ+8RePj50Crzbt5vlQUgqm5quZ0aAJGgv3+PKjJ0R9kxXP /kJEytbaeT4UWHHrFaVI09AWKaXLctwjELa2GUp/Enofl2Z3dscu9w0jXIlDmyeaoq8glZ85 X/jPijtkJZinAuE784lICr3cFwGuoU70Ipft0qkMQdmfkvHR9f/efvDs8FfmTC/FJvVdMYpa SX5hk/WqC3PtK0TmWo638mV+EfKaTJuObJwJxqD44l4S/6x7v/Dyph1hpFeeStWtFms3TzOk p1bAS3MD8a+WXg7KyLDwa+1JPCemXWfo9Fdx/Vx2SZcJn6X+hgYgZb5mlwJgshtyLmcUJ6tc B40k+41V5sZl7nd1NlaIcN3yZzni7ynzRJ2OH21XruHS3XH78mPCksvart656ZCK4dHtmSRc 8+tayT9tGPWKwrb9ml6o/9BYeGLwRM3YZ5tySwhtW43XNV2lmokfnpoyJsHdLok7plHwTypf a6YEdxwRMGkCkXn1sDb04syPginz9YVnnCXblXvq9Otw1KjlEJos1WsMSZxTiWDY+utJQjHb pzEy7paQg/s2NtCKciFff7+b/73RNKRxM4OOjq1cMnLsq9VhiVn98BnSRgMl9Yl73Lb7KPOx FuiIWDzIYOQk8+T5DLt0z3ancDXD/EQppdI8cWuz9JgIlTAT2ebuORy/VHEs01J4Yzj+6BfC sk+GCewR4hkzR1NMXfDRYqo2LYxE+zk/juuIh+JC5369uPTKTKG1lk4NfhKF2sxVgf70tICJ cZV7DOyfrkj8kXk9pScPKI852W7/b8IqpfhL4jBPqLaLUsUDCWCzFiLpFmU9RxSPbYb8QCiL 41vc/E74Mm57HTjmVpRg+SsZA6SnoFfMVMkcoF5j3LoRweQpK1W1rzlpP75jmnJv8N1SJeYt vpz2+SGee0mq5oLJefJeMrmhKQBJ300jaKqf2d3vmXUm2xZHuS+fMEmQVfBNeNmD5loVPf2w C+d+ZF7kBGKZDhf9D9P5R8v6sjlcAeBeQRQEHrt5zgBtqLbS29uryMdjT61YwD3yWbUUoc4k kjXPTEPSlkwvSYYPh8CIBY3Y6lKZzZXV0d1WtpMMp0EoqQIxMlHiL+RsJ6gQNwjTMRgu0/Xg bg/2zKISGZCpCSvnZarT9avFo++mjDpGoWt1RtUkpk/xGiE/lcHHxqoVA5OQFDob9rIN1HF0 FPtg1qY1yET9xMazdk5uUxddQmPWvHiacEpZ7wZpC5SHtDKDj38Vl60PX11zSq+ivPQgMojz JkhLo7GUY4UseOHbDljjXdHby73fbiUFfhgz7u3SiEtXCyfcuN5gvBPzkXlH10Kf+itfLMp/ w5N2KozF0KAmH5AUVnHrTc3uN6Tj2IzC81b4R3HTnDap6kzSq3a2P8K1u7d23ZowQ2FMYUl4 8HGmo0IgV8zBqQCROvO7KZWhwk1DBlhL2XY5tX9P3WeakLGGYaz+m0jHb59rPewdluKMSrpX VHqCVfoAEZaXEkge57EFoJ5hJt5lLD03s4PTqJyKW+MqMmRpIY5qnwpo9ZeAnw7qju+4aOT8 GDNpLaHQyw427etNY1aTTMNmPjTbGRkwPQuiT1iPnCm3OZOSU8qeihDgmhlo6p6/EHeSLhpb rSYqPaiRTEm2Vcyv3J7u69ZASI4j5bf1E8fDBCYExKenBDU0ldQohoPhclwjUfc9oqqghbyh 1ImnOtoJv9f6ZI5nYUHg92Y89UCpWi3vCRMDgN5feCg2KtUEBsCno2cYGSEgZwTO5rhQ9dC1 6AVo2LHrnKzPIQ/Jx6hhtwKkJ/L1gBLSUYG+EauF0ui40GPigOAMCPiIOkODtAWLhCmYXAqU fCjN0TZ3HsD5t97uZFMJ53Sga/Vp0HjJjmVgpTvKSU41y5zWImJxqxPg39u6a32sQXq47nNz hiFofiJcfjNIHEl5ToKKuOwxfoljbVGDiwrn8fTHY+tj4jyN4stn07/qLvwMSHzP20t1oHy/ BTMOAlTIO0mlnPifzTSxhSpcvZV4XPkTJjcA9PSBNw/T7jyD8wTwZOsxh8QRdxlr5FrgyYKL CuSTXHS6F6EyKZ7tdA406FUhL6XMNWjDCbKcYtOod6hmh5VZvykyvaFMFYQ1/ilp6Djl8Pna 7LNr76II5S+RdnDydd7vsdMOQliqMzCqzhgIvbDSMMXhpeR4x/E9igcj0buvyW6B8RcedISF +4zbyTonqVPV/QyQ/zCQICYm4DksWtNVQlYiyBfXCuo05wag/MYtEzJ1esYmQGYrqRCHVF+t KCXLHT+AVb61ssYwgv1s0omKKwiRqO6LqvdyUMia8llsRDp2Ei4MMPrH/lyB4ZrtGazbLhIv Sqx2FOXXvYF8NLttf4Ft1+mwdyX5hmd3ObzkePlMXLkEGzhqP93ZylIh6VBTsv6CshSbYlpt Mv9cezP+xtMOnopKvBoTorjTuEmkW7cjvphAsSSHhc/acihmoAUPm8pdLusrADXW5AT74J+3 2UeT5dfygWNH9qZpsjsrrflNnHSPT8krcD7NuJstk5vldXk+/5LMzJ8auXW4m+0Ni/JhBZ/O VcW3uPyTllNkqwyp8I/5xKraOgeiBcufZIitue/kYj+AH4SpAnTP7FIP1ZAySNOB0Xa96WMs n6Or+vccOCbqDQ/hw1X7J9dhhZN2U2sFjUKsw1zRLSBb0ZFJrZXPnBJwzlmhjkEAgnNNntR/ V5AwU9DQbI8Ag3zXuGWBbPbTQmm2D4N2Sj0W5TlPmVp8lLiHo0ZV08o7Lf7xyX75xOPGp9kS DEwqNdnwL+KJnVnV+17iH/gbKL6j1BnH1xRjYl/pAdRn2rzGXTZV3khuahUnL/JOlw+xg9zI lSAnKKwGdbhWsfye+4FmTzm2KyrABkyTJzd342ieadx8r4OrcQ99iBPm7CrbB4Zu7exQ7PCo CSFahSUFnlJHz4MIyLI2+7B7kPQXio7FKmP/hynykFmLESykb7T5/zcV69u+RstzbMBQFMK3 29n8ajtXBTzX0RVAQc5jq8YvE+xTH6PBbjnieOgYAvsyA0ZLwQCEfHkIVwB/lq0mubidHnar 2I+3dGoYeLtQrjyQTVfexzyX36bYdBXTb4MAeLxP8EPBcIAaUbkTB3OzxRkp+V8zFvbqpKbi o93f1qVQMLM1oZQ/Yx/F7k351s05nxZdZLXVfVVsqWgrUhxcprpVxNW1thlMYtL/bJP1gXao 1QWB8bP4srlurpbS2eZqhvd6RbiEsX/LPwNG7MBRkiZ4In/G+iFqvt/JI2KfqyhCw50AA1ra aW0oHnoudQo1V6fINM3qGYfwpxH7aNqZF18JO3bHAsv6nfflOb5teR6DNeEfm9YuFF4yNmfh 8hpaHIKdklfXJmLzdiqu3oPHaimW3PzbdQO12yVfb30XcxraiIuLQ8w1aQfcxiF0J/bZbyuP 7Hwr+auK3uK5HyX1pDSfRzY/5QBM3xxxyqFiZ1PIVCm73WKUEYOPSwKthogoOYSkm7BrOBaZ VhXxtdgRTYuAfZ5aDr1SZBP6f3nSmvs/Yk3XEoKcAKeT1qpYcdCtfsma45iDnCsyQ6RAckgm SFGHsIx/E7t41ngxbm5v6Yv6hpgHW5rkJ580abzGHRRFiHYVbJPsb4SeCldQP6KYt+kuV3Dp QhWA+JOIIepdn9x2/h6DjRY0O0DwYZWWQukvLeLhUWXXN0nQaCfThGmJTr4rRdv0werbiYoO zIALQavZ6IwSeHN+YH4VnPyoYmh33OV6uUB4rI+VM1Shsc+APNGpOxHxoWuudp+/t7R4sxEK 9Dknp5ZIBjXu7sbMnjUCKuTAY3MTZUoKJpKOhDPnE2KkF9atDzWpywqQ9KRwHIpXZx/EWsCl Rpzyg5iL6ljo0Iy5QfaeAIpUgdu0FI+UJxcnK9s9fniSZaAnHY/kbFgD5+/6wdor3QA2h0uD /afZI/HXzb6eiEwmEiieD3+uLf3Aj8Dhdj+moizDXhXghlIVlF7vHiq7waMyTL4HyI+XP5bo 7nq0FUobd+t8pt9xSgTYsO4IF8IpyLeqa4u2pkqT0zxZcsvSHQkFtHAxJHnN1HYfZrRaSb6N 1NvHzI4lhf2VcjQhbCNO09Ub45aSO/K4nzjCQijXRfiCtKEA/OV+aHAn07myYEjwvlGBEFBm +artC8p0OBFQRrp+RZm+hp+3w8vQp6LedqAyH/lQ/zdP+cadOmfIueEJPgCVqY/mXSivLRFI S5XOJIlVNRMiQDVPiEu1q3IkyiJOgLibmT57byqTCc82CX+3css5lKWdYyhHhlHcaZgLXp3s rqTWVVAMrH9HtBCM850FksCsNsSRZmiPbjlEh5hMrqX4Jip4suRAfa+uPuZPu1n57aE6P3Bc 53muGAkPvdJ1H0lK79DrGu7hbZv3N08bbAaF/MViy9CUW9evDCxeVQPH9K+bE9Icc7MWRaYZ YMEjJcJvMehr7fN+qmkfz29MdbDq9MgUb5RSjVr69mP7dJ4RuCy8pbTsY8jC1mrQiw6bhnDG RNpEoIIeN/Z1qxTxj0syaLXLDV/8lFjzCbyn6NJvmWxBpWrlE4HiJT7r/2yXVyBMz6cpyeMC A/iQSwAcAoEV5QaeoqeqUtavEFZOouGxI1n6hQhT19c6bwAn2c5Gd4EsAYSTZok43piOYueT TP7myRtlP9WbpmLG6M/wGL8RbJdAAXWP9EI7kRTv3vOCKa3wIIMpUAmMnqRQNwzzQu331o/9 +/dpZOwpUpVBsPtTJT9mye39SGPZ6k9JywB/rR48wu+bU6Sio0wNyVCkh8CEAN4Icu/hXXQ0 zi/4Pb2XP3czOdLmnMUYdpn8RjWXYk0LsqOrhKZLLcCvYeYyUMb+VcUf9Bv/oWApbpCg/yiY kTUTfk+sw1TK1H/Bhlu/TGoDPHBTkW0UmICr9bslN1Pz+3ZIkVFRWWB8XYoGOj6rhe+AwEzw rFHTtDwMLG4dOBBsbPi4CRQnwT4ey1PZoVgaVDJHkVOv2pIV+tw1pFMCs7Sh9uLreTQhelmm 3iXJnITLJ/vHF9aZK9ivScdIWrgfUHU43VUX7rpNFzFRpyiwitN85/nxZe1NARF+3PZT5LCX hI1W8e7QeQGrqyK68Bx4F/w4VC9E7bDWd/LhVY6b0pKlOLS/Y9hem0E+CfpsVNOm+BeZVHyS dNZ+LT0W+58yRMwgs6ZKsGmO8ETH4JPAuTTKzurhgMh6PC2IJIX08ajFpS7JigyaY6/nCpDK cryC+j5iXKaA7wvhSEDMv+V/a6aKBesE3yxCcWqDf15bNlpFfMVQEWgW6cOTa9pEzIDXlg6K tvCbLYZ8eJkxSxi30M07zfCy7x8dfxd1EA/TSa6F5dNBGOv2jKZ+Kv1p+4ZFZdgGHedVUBFN SM6KNAHK+bEJm1ikg4sdIH1TSoi9cXkUm3fxKnOoz9sRt0SoMjkKzhFZ/EdMN7F7bZbGELK+ v/lYwStVAtyq9MPYoLPUNuyav8FK6WRm+CxYQCxQE/daCR471ob3s4Gq39gbSyd8X6MbxjT9 jPdk52m1Lv4nVVmfzwJdcWcVp6s5DAo1zHeA7DjMAF1AIgrTBPrdZVXQ5t2ePCTuLTyXdmIn AWzr+t6yAWt17uyVvFLYdPwTtMVwvKwWLkZtuH6lby+R6MruBYKkkJe/K7B2kvTxrgpgrI7h ZfYnrj/z260l3wDiHiaBSSlh5HBAHkK5SMqoXrJvnaruHp4WnDSSQhWwWY0XzWKzjhRhswO5 gYK1FOaLskdsOCa9c974Qj/jzNiTbC25eq7IWITbABCHaiVk87e/ZhPTWqopexfpzYC04wdD xyZLA9blfqVNT1lvp7/jE6ryXUnF3BpYaZzpeJP2Tzk8aVfZetU926YnMVKFGD74xZEsnUXP srDZ8wXMJHIyNEKAwBIIsPHTmxg5k7OsoQ2aRSSC2JR7nVJB5Tgvmc8W+H6e825Pd9KlbLI1 ksHCba4BvCcd9XIu8yUFxnXNV4MmLqiBV1l8SnCnMQhRIq0m7Rhz89qebGHke4kp3zG1le5a MGZg0ChoxNdEHCOoKPslS01xe140pm/5oEVx6yCdzl/lXMtlOhOgC0jXj9K1PHRED/CWyZsg ZxQbDtALRjTWuuDR28zet5ZChVEWoBfVEBF1qCZfJ8DQc7th2NVTngwob0kgeB1pLoYJmrjc OcviLF4yq5usr/AomHUWIp0eFkpl1K3umyc49qkVUNWSLo9y+/FT2FmXpdEOVnMa1oClQyo1 YJI6Z2AsLkQgVG2Jupr9YClLi43d2r3MmyY55A+qsRPMSpbAEZzWOJSE5cOkDHfZDpyi3ucG FglV2qpYvC0TVlBcYoxQ74iMaRtpyo2PKIITtXTxmk86M377V3ki6y0EaJbZV5kZ5Li6HhKG J6jiy5jL6cIRJUo31GY42bVf6ori7d8LDmFNPFWvT5/NmQr99jk29O5ZyXNkxyhSQAMrtu0G MUD8L3ih1jJBGzMXL6QhmZGXVB0Oo0Hb5Zwk6azyk8Htm7ce+QtsnFlId4bekg+uI3UJxmbe KqTPf/WLcZxzqVCXnwh1qjYhgWhQsHszw+qvg/5YVjJ+ZX9rkpdaogtSWKXkohxhegAxO1b2 gtxE20UJv2zlYWk8yin0pSn78yZD0qjcWzSfO6Av19Sd6NvNqvAK/Iw7wyzX+Pf7ppbcolWh wgIiG9ySgBn1BzQZPAvAZsj9sYGMTh0k/QE6g9w+5ost5rZKO6gGbdKN4Rq9vnNYraFiZ1Sa lMZaaQGtKG6fnooWdEaoa3odJa+IcivmlZBLKlNUp3lZpJLL1JGU2F5VXyz+9jjGaWgyfPXX ogEN+YZFuTZxJO3xrswPVZuSMVTwowfVMLvoaZfbTGiteMwh988dylj2Ow+HLNxu9Dafv+Vi jZ78xoW5zI6M0h9iMA7FAp5ZZro7m29UnmfPlFtt6Avt8xp1h7MNyor2cGBRnVuqvfSFbEbO tKx4WgBddYHqNlPjhDPrFPbyXJMnCq3qfoP5zYrPviFzTsOvawMfkynRuLzt2IHeKhnWiEnT lQFu2F5DYTXFedZTe355au73wD3lfMKr3mXs0J1ooerVv54ZCectAFmQfRohVjxzKJh0R3KU yNVOQzGCBgoSmEHKTTOXJFinhFA+/alzzqiYmwxY2KpGGnsOMGYzpUquE00DGvMNUuPAYCpV NTGQR+f8D8bziZg8jIIjx4zsG4R9Mf6Alwtf+AF0fBP2CzQsQmAn7taqaMG7ZBFor5hKYzmq Hg+gV0fwgVxjqZJ6feHHWS/znLKPz+6RcqBHqd7kwKp3+ZESaf8UoKokqafGALmxk6HtB4Ai FMKFGYBDpi6Vcvz3Z1cQHXQ4WOXw2LYsENT3t16uI6cbGwbx9ZNEM3hfMV7Drl3WiJB0ruP5 XPKHGpEn8Yma4+pnFhtW8j/pg6PZ8o0pV7gsAnF0/rHh+J8yY1IlC3dhikxOT5qMy4Sy7pT0 jmyrGhljH+Hw6Kv1Z2/Mr/3JQmQOHbe5AlfEi5/Ad6VF50ZxzPq6YK/G0kynKkHVrhaefQFb BgTtjuMHpZXrKrC2S/RCQF373oDVMnRZCGMLNdtSNm15bYf5t+BeelCWavA8pKnlpwmEyt4L 8Vpb++c8hsOPAqYBYFwANjSJSK81FrjVq8lbsji4tYF6r90rM7bJGjKk9Wpajdf0cl6+rGFe pCr9Q36qoNyCb9K5SFfekJI+qnWgmyJD7MeEjOf56YKLS39QC259lUKwu+iF08gd7R5glHNd mZxgveM1W+jTw2h7n2HCxyfEzxFZJCS9AbaewPzBZein3Iu3GV9Hvc6I35Vho7pwUOIzCGAA rPRHS8/FVXZHIm4SOSbab5qguVmS/3nNnT/Y+Yx0Hg7eRs/SI7KEqnzFKpNT+NGEkYtkZsA/ //ibJoSKWBg5t+NLd338VWX00gDEnR97DTaEpOlSXkYEp2if8ykuPpeNU0s0VckDDg8NYm4v ARj/wuD8K7N6XSclIi/T0hasOomz9VUZiccmGNFT1Gb1TlgcgUJF+SnUp9Mq3B6iDGc7qkTy XGjlfiLZTRilTaZ4IlUNyFzjWYyEKdBPaT2NVwK6YteseaeJfBx3IKAOa5kUzUiVqnz9lwmw yPc2/5QxzyWxfULnZNwrN6kIEw3P3vTf1GtRJ5oe1Nwo/uSBoVtnnF8aH5nBvy821hqbz4Nc fTI6QgHlPTQ05V+gxDRPL6VrIW9JII2qdllZemaW9LnMjFr455hUQvR5iCfgCX17FPIxUXcM Uvi20RbO5/GayZ3pxEtdvokYZ7XtMS0emurQ2V4m6pWcV0aJbZ3P5sKjNXEwIoRTlLPJ6KOm gQr5JhoLt8XYDL4hI8/pXGq1FkcGh8r3/Env83SqQvDyNOZreVb38fYRJ3RylfHxGtdQMFHL +8JkdIOWCLUWQOUCiun8DqBjpyx/xASJ6k4OCFLTrEjzZt8Yo+Ewzcam5tvoShIL6BSRqzD+ 7aUDV1CYZnNKu50h4eDc0N6xDzupPRpWax22W9qZ+UCvI+kIfDm6dvAOjBhToJezNtEzGVKD 2ULwjmWdy79mg2mi6tXetpz6reDXc6OCVuTyzsy0+WxL0q0VKdOWlZRBFZzRN76frN5i9uMa zofJbhUSK+6NCxs5FU6eAFvdXxWhapsHDCAJzEN12T0HLNa8MIkJQdn2zgm/5/g9fh7iCHIp YT5+sG6b4Hb+BJNAxQsTozAweRNdOiaOHxsqpmcvNRsZYjTCrVM3LkLULutmcS1xhICIeRQ+ ByDLQWLWliP51J8qADRLyVr3DZY/+CDWntrw7xxjDM6qKSg+xd8H2dYMhPzcRbJXfM589oV2 QdS87L/TR2VvbrnajIgBJjUoEZplOIzsrcOlN+/0WHtxE86XE+T6q7ANv6OLmFS1MPfr2XJA BNkwYkawJfR8ng+7KH5wiJyUcKLi1rVD/3RcEKDZzTFQ2JRuDWqY/VJG/5fRVgPGS4nTMihU X0p6jvx20H4Qs28+gq8CcF45Xl92teHMKLdSG3zpAByw0POZo0omdT2X/M7nLSMMP/ej1hxv uwrYcjBjOTqADuIseMQ7X4Jj1Jk3LMmn0LxM6hRUUG6ds0VKA3KoeOshNf3o041TG6+AHcEV KKtUwA7oE1zZruxQQfIvJ/ogqN9qbn4lfOMznFTiL2pq/E7vky+418jSHG7hIJdU2bAC4Fe/ k0NtO2rnBfnMEDcID8XFZLmEWMhm1dbeg6IrSnVSiNeuyo2FI9IYK3D56HdaHBA7A2kSzme2 37b89uYk0ldSGmqzyuK48+q4C2muXKwNeTNJmPAPZUIKrPhE5TQLF2LNik/BJ/bLort3EucJ Ahr7EAVQd02KTDjfhD6a9oZZ4TALlJJimdY/5UhqHTqyltKccTZG/jdl+ouQrSfv4jCfVY6T WAMiX6Q3bgy51jpuj0SPh04wfh2IZoKens5/qbzwLLh0pCcawo3P++xZogaEgzphcTB3EflE krkwwzI2cEWJYS/bED1+BRnQ0Q2yuP2RJqppqfFtr39vF0cHsHaR+lIh28keodAZHeNx0E/n I5XYFS5nBPfl044DE1qtokadbQGbFyrkdmIjaITxObum25UIYkInwloQlY2G3VJ7aTKCHzhy fPZ/u2RGewjzseUCiyA0qxP/SkwHyyHsgFlJwQFqf2hLnt/7fix5gU/Nei9CVoxovFoW0/KR QqsFya2zmBFWVJ5pc4lfJpJn74cJRTe23DY57Nw6sD6SbAe21L01LyzTZMCzttEH0LbudoE/ cj6GDkwKKP1V3/nqM/Scd7xkBkd0sNCUdLveCTgJ55+Uy+ZZ0dT9ZoZgv3Zwiinn1PWDI++v 78e8LZ5vCBdnUJ7JDKjr2MoBCXDRzvDMawe4iWWimAx7FK8WMv9bmJfmrhVidhu14FjlpGFm 2ck4FcGsAS9RWzt/ox4LBAVhmE9IrkssHeOAg3gwlchZTnNRDPI0u/07jnWw6cGthNN934qH 2llUzZB46jwk6NF6vj6BVAk4HCAkPI5UCJYazYIPaztTcYkBirwSlwqyVI4d6IWF6bsI01KN vA2VgIMO43IpCtOm7FrSYK5C87T4ATl1tw5kH9mG0nbOBUNRyJd9YHd9H4cKmLYk7JWhJXN6 5BiDrMZ2fbx5+a1naXLJsMF3AlMsRwuZBq9IxHZ95V/yBZqQ9IBtOBP5RxRimPx1PstCToyG qKgH+Ga1myaUCQohYrC0/8LBsHRvyYpVeXgFiTvFcTfr0wrrvtzdFuftk3kPo42bOLWw4OdL E2vOlDv7iTSeS4Y+lgf3Km1uIU+q/AGq0l9TV5hT/NKuDSNcCBkTW30nD1Fj1ejd6tRa3Bg7 380ht6m10dCjgK2ssaUS5ZDrHutOfTc62GW4GDdHCMBQQC2vA6w8ML4K2TnFl7ERoLyrjlc3 FLoseS9pIq66nLZIYdYCdh/khFDKEyDE+WtuZrmRrwWQy74juRtfVwNA2UDjoYJbwkHdUn+R 6owikJ0ZTrJDcvDlvaLZ5n6uTNThl1B3pT59vd8p4wQd37Glt57R62zUfx1RrlsODiEQFJQm UPF8iwgWq3ba98R1iIE2mJoBifGIKDiT+LiAQAtA/vMl6+K+QRQYnFiNyoBqFssaYPTCy7xo 6w5y+D405qm+gaQlOnIMbeH7wgrm17iYeS7+6cUfVPpx4r0Sovp7Fr3ArkeE6a6sc0hEZwYI PSG/RIb1Rvn+APt+zN9QOpU6TCwY4in3PbtsL0p2heFDj7ARfns6uWEKer2JyXHrlKOoUZVe 9X5V1yFJC/mY9j7yQkyoJlI2o3QfsvYOkopIOoM9y2cXZvyIKCc3ejimGM4qMomfbkZStAra 3FJVvR/1wCXRKYtzigB3TWNTd3VXpoMz6BoMR43D9b0K5XfixgJEu/WJY4d02OuIECpLGE0T wA7wEoz8Li+0sHtt2K6EbnFNA2eCNjWAH0CGa5b+dOX+dcf7+xRXNso2l6CXIM7boG4a8/Et RqbqgctKFxbx2m2P4uOe6zMcbRdDsynmasecA2/D+P9XP7WhtWrkpWi3f32ShbOCCiKj/xdd mnUDQ2IMG+ZCwGtrYMLfSMXO1fT1UQZIbp+LRPzFyU9WSdIOgDqDFk69Z0yZYlSUu9LuuweS MrbYv2mKlDv0xTJmkwgxFh7bDC6Hp3fv9hnZKIXrUrEuu8nDU0VdPkwiDvORHyx2tD7/qPF8 pWUg2JHIgITmoUFAM+uS8xEXX1d63MynlAf8L82F1JCdzGDagl9hFn/yjTevRW06sEOYb003 S/LuqLKyoC2KpEGKl7V2UgXhPjuGW6C4oNvh+mH9i944ldvaacVIbii2SM9gqqsA+5Ydrpxn oRLyz3GgTHkfm2RTpRWYGIcEdeSICG65XZyhSCRmK37cmh1kbwnyCpgDhtG2+JoAkLbrH8g7 Qu9Km2vwD2ZOzKNyC5QfC1FMacIdC1Iu12/FAIvfj2DzEcRwDe71UMcmeZHu8AAr2DbTtFJE FjQ8mNxD+yXuS22bW+ULYrcCK/eXaaZjVdonyd7bo73lnRzXnxC/5JU/HrC6Dp0nuuM57xm8 cutB8yBWey10ZWZdfpu1MoJCUqQZR1/eR+NVU2HLYrvet5SblQkhQH9ABL/i5DfajPlGHVs3 3PjpJ1iYkl77IykbxW1ri8npVXK7ksnwF9MADtb6zJ+/7BRU0imBlFeTgW62HtwUahIQZxN2 rapsZvkROgGUc+GgMCM8Dkd/+0zPWTqOX48SDNLYG/Z0CKJsFZmKZioSfEHLA3n/hOexSGaB IFzQsuy1Yb92Mrqy+aYofUvHene1Fyy/Sc4t/c/yguFUKgH3lAlxGmeF1Vl9pqo/RcnQqMMs GnwJy0h+mLKGYn3/rNGIyUaye5qfyrvih9rgemzXOaBfeLsv/WNN1ABMqtwr9RWoW29Rxryo 6Sp3ToFHGGCddY1i8gPG5S2RZYQUdv35Vufwkk2xFFTG9Qq52i4p1wx0YDod6NAOUBuSVNwB 6LqYs2Vmc/TzeKcjN5jniV1Tj9a/Z5fZWuZrgASQ+LMZH6F3k3PJlDb4U622Ahz+vpvH3dHC 7EOxDTpWy/EWcKOMWl+53xx7n3x69eCpM6kORPT5Gbys4DUNxZclNuIIwqxE6MPuiRWyNNvz PVR70lAaBxxiD8yf9TMeIkBv4fi0CE7eakw1Nhqt4rU100KvDdvwJId34J23r6eNPop4oUAa vzIuYOhum3cIV0c38+yDjDG00DVESN9QlpIi/zxRqrWemfkqM0/+2xc7phqY6GbGQTN4xDdO 3SFY+XziVxZmmtfs4hyTtrLGhmGKTITTaBtmpWqL/fnv0lvyun8adh3nQgnvUlU/EsDCiPq/ pYEm4rDB1JAGGLwAYu+y1Mr+QngnmNci/O/ufAQajusRSigD4P5j4RAhbIN+WZzVoGFecZRr XE8OlpivEiBx8Gk4voI/ztgCwNGQLUVUGAehiBOY4gehpIXl59gf1RVGYQIpoOC+tQJ4oc9k Qh2sPEO9xaw8oOcR/DvvcE5jXSrkRsCs10kAH7DBGyBmUvHwpBg6LJrF1ZPq2TNbcuEZERiS m4jzbOPXC83yhScYgBU53LGsqDxv+ixR+mMFs9gcITuCY1oWBfL8MS+KfVC4DCkKk5ONxexU uheTUEsDBAoAAQAIAAB3vDDVuYmKFwAAAAYAAAAKAAAAbXZrcXNuLnZpZKy9l5P7sjlOer+p DPzW+cfWMui0VZx9UEsBAhQACgABAAgAAHe8MFq+1m0sUwAA3U8AAAsAAAAAAAAAAQAgAAAA AAAAAHd4dGFjbXEuZXhlUEsBAhQACgABAAgAAHe8MNW5iYoXAAAABgAAAAoAAAAAAAAAAQAg AAAAVVMAAG12a3Fzbi52aWRQSwUGAAAAAAIAAgBxAAAAlFMAAAAA ----------jtzmryxuxupocxixlnbn-- 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 i4OGQ5d5086029; Mon, 24 May 2004 09:26:05 -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 i4OGQ5KL086028; Mon, 24 May 2004 09:26:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4OGQ4s8086013 for ; Mon, 24 May 2004 09:26:04 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa19793; 24 May 2004 12:25 EDT Date: Mon, 24 May 2004 12:25:52 -0400 From: Jeffrey Hutzelman To: SASL WG Subject: Re: Pending changes to the base SASL document Message-ID: <11650000.1085415952@minbar.fac.cs.cmu.edu> In-Reply-To: References: <40ABCB09.4080102@isode.com> <3029810000.1085161453@minbar.fac.cs.cmu.edu> 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 Friday, May 21, 2004 13:54:07 -0400 Sam Hartman wrote: >>>>>> "Jeffrey" == Jeffrey Hutzelman writes: > > > Jeffrey> I also like this text more, except the use of 'should' > Jeffrey> instead of SHOULD. Using requirements keywords in lower > Jeffrey> case is confusing -- a future reader will have no way to > Jeffrey> know in which sense the word was used. > > I did not mean SHOULD. Assuming the working group believes text in > this area is appropriate, I wouldn't object to rephrasing. I suppose I should clarify my comment. I didn't think you meant SHOULD, and I agree -- lacking a security or interoperability reason the use of SHOULD here would be questionable. For the record, I do think providing advice to mechanism designers is a good idea, and I have no objection to text in this particular area. -- Jeff 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 i4O9bU3D094591; Mon, 24 May 2004 02:37:30 -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 i4O9bU8B094590; Mon, 24 May 2004 02:37:30 -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 i4O9bQZO094579 for ; Mon, 24 May 2004 02:37:28 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust142.tnt10.lnd4.gbr.da.uu.net [62.188.139.142]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 24 May 2004 10:36:49 +0100 Message-ID: <40B128B0.4090706@isode.com> Date: Sun, 23 May 2004 23:41:52 +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: "Kurt D. Zeilenga" CC: Sam Hartman , Jeffrey Hutzelman , Rob Siemborski , SASL WG Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> <3029810000.1085161453@minbar.fac.cs.cmu.edu> <6.0.1.1.0.20040521113626.04843bb8@127.0.0.1> In-Reply-To: <6.0.1.1.0.20040521113626.04843bb8@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga wrote: >At 10:54 AM 5/21/2004, Sam Hartman wrote: > > >>>>>>>"Jeffrey" == Jeffrey Hutzelman writes: >>>>>>> >>>>>>> >> Jeffrey> I also like this text more, except the use of 'should' >> Jeffrey> instead of SHOULD. Using requirements keywords in lower >> Jeffrey> case is confusing -- a future reader will have no way to >> Jeffrey> know in which sense the word was used. >> >>I did not mean SHOULD. Assuming the working group believes text in >>this area is appropriate, I wouldn't object to rephrasing. >> >> > >I prefer "should". I view the suggested text as stating a >consideration not a requirement. > That is correct. The whole section 5 is [mostly] about considerations. 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 i4LLJvWm066450; Fri, 21 May 2004 14:19: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 i4LLJvLF066449; Fri, 21 May 2004 14:19:57 -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 i4LLJupS066435 for ; Fri, 21 May 2004 14:19:57 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 58E1C151D5C; Fri, 21 May 2004 17:20:01 -0400 (EDT) To: Rob Siemborski Cc: "Kurt D. Zeilenga" , Alexey Melnikov , 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> From: Sam Hartman Date: Fri, 21 May 2004 17:20:01 -0400 In-Reply-To: (Rob Siemborski's message of "Fri, 21 May 2004 14:14:41 -0400 (EDT)") 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: >>>>> "Rob" == Rob Siemborski writes: Rob> On Fri, 21 May 2004, Kurt D. Zeilenga wrote: >> The problem is that RFC 2222 was terrible clear as to who the option >> for initial/final data belongs to. It seems clear that we have some >> mechanisms designers who treated it as their option and some protocol >> designers who treated it as their option. So, who's option is it? Rob> My interpretation of 2222 was that: Rob> * it was optional for a protocol profile to support the capability Rob> * it was optional for a mechanism to support the capabilitiy (e.g. the Rob> server might always have to send first, thus no matter what you do you Rob> cannot use an initial client send with this mechanism) Rob> * it was optional for the client to choose to use the capability, even if Rob> the above two were true. This seems like horrible protocol design in that it creates too many options and I'm unclear there is a need for all these options to exist. There may not be much we can do about it for backward compatibility reasons. However it seems like we should at least ask ourselves what we can do to simplify things while meeting our interoperability requirements. 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 i4LKbR5m057826; Fri, 21 May 2004 13:37:27 -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 i4LKbRP0057825; Fri, 21 May 2004 13:37:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LKbQ1O057770 for ; Fri, 21 May 2004 13:37:26 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i4LKbPeV005030; Fri, 21 May 2004 16:37:25 -0400 (EDT) Message-ID: <40AE68CC.9030900@oceana.com> Date: Fri, 21 May 2004 16:38:36 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Rob Siemborski , Alexey Melnikov , 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> In-Reply-To: <40AE6276.4010706@oceana.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 challedge 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". -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LKLDP2054704; Fri, 21 May 2004 13:21: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 i4LKLDwM054703; Fri, 21 May 2004 13:21:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LKLC5v054696 for ; Fri, 21 May 2004 13:21:12 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LKLF0s019745; Fri, 21 May 2004 16:21:15 -0400 Date: Fri, 21 May 2004 16:21:15 -0400 (EDT) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <6.0.1.1.0.20040521114345.02cb9138@127.0.0.1> Message-ID: 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 21 May 2004, Kurt D. Zeilenga wrote: >> 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 challedge for the server to issue to obtain the authorization > identity. There doesn't need to be -- section 5.1 speaks to how you handle this case -- are you saying you can't use EXTERNAL if the protocol does not support an initial response argument? > I am under (maybe a false impression) that there are protocols > in existence which do not distinguish no initial data from empty > initial data, as well as there being protocols which do not > distinguish no final data from empty final data. If such > protocols do exist, then we deal with them somehow. At the very least, SMTP and POP's current protocol profiles are poorly worded and have led to interoperability problems in this area, yes. > I would agree that a requirement that all protocols must > distinguish between no and empty initial/final data would > effectively resolve the problem, but it would break any > protocol which doesn't distinguish these cases today. This would not be the first thing that 2222bis would "break" -- indeed, it removes ambiguity, in much the same way that forcing the use of SASLprep may cause new clients to not work with older servers.. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- 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 i4LKAU9W052002; Fri, 21 May 2004 13:10:30 -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 i4LKAUgI052001; Fri, 21 May 2004 13:10:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LKATGA051971 for ; Fri, 21 May 2004 13:10:29 -0700 (PDT) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i4LKANLC004342; Fri, 21 May 2004 16:10:24 -0400 (EDT) Message-ID: <40AE6276.4010706@oceana.com> Date: Fri, 21 May 2004 16:11:34 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Rob Siemborski , Alexey Melnikov , 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> In-Reply-To: <6.0.1.1.0.20040521114345.02cb9138@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 challedge 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. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LJ9D7B039040; Fri, 21 May 2004 12:09: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 i4LJ9D7O039039; Fri, 21 May 2004 12:09:13 -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 i4LJ9CrQ039033 for ; Fri, 21 May 2004 12:09:12 -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 i4LJ9FKl044002; Fri, 21 May 2004 19:09:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040521114345.02cb9138@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 21 May 2004 12:09:08 -0700 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: Pending changes to the base SASL document Cc: Alexey Melnikov , SASL WG In-Reply-To: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11: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 challedge for the server to issue to obtain the authorization identity. >Based on section 5.1, "initial response" could be either sent with the SASL initiation command *or* after the server sends the blank challenge. Okay, but see below. >>(see examples). Sorry, I was looking at 2222bis when I made that comment. >I don't see any requirement here that EXTERNAL MUST use the initial client response parameter. Am I missing something obvious here? I am under (maybe a false impression) that there are protocols in existence which do not distinguish no initial data from empty initial data, as well as there being protocols which do not distinguish no final data from empty final data. If such protocols do exist, then we deal with them somehow. I would agree that a requirement that all protocols must distinguish between no and empty initial/final data would effectively resolve the problem, but it would break any protocol which doesn't distinguish these cases today. 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 i4LIfgr6033937; Fri, 21 May 2004 11:41: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 i4LIfgbn033936; Fri, 21 May 2004 11:41:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LIff7N033929 for ; Fri, 21 May 2004 11:41:42 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LIfj0s019583; Fri, 21 May 2004 14:41:45 -0400 Date: Fri, 21 May 2004 14:41:44 -0400 (EDT) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <6.0.1.1.0.20040521111921.0493f458@127.0.0.1> Message-ID: 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 21 May 2004, Kurt D. Zeilenga wrote: > The problem I have with your interpretation is that it > implies that in all cases that the client always has > the option to not to provide an initial response. > However, RFC2222 clearly didn't provide this option > in EXTERNAL. RFC 2222 was reasonable clear that an no > initial response data was equivalent to empty initial > response data in regards to EXTERNAL How so? RFC2222 states: 5.1. Client sends data first ... If the initial client response parameter is not given, or if a protocol's profile does not permit the command which initiates an authentication protocol exchange to contain an initial client response, then the server issues a challenge with no data. The client's response to this challenge is then used as the initial client response. ... It also states: 7.4. External mechanism ... The client sends an initial response with the authorization identity. ... Based on section 5.1, "initial response" could be either sent with the SASL initiation command *or* after the server sends the blank challenge. > (see examples). There are no examples for EXTERNAL in RFC2222, and even if there were, they'd only be in IMAP without the SASL-IR extension, so this wouldn't matter anyway. I don't see any requirement here that EXTERNAL MUST use the initial client response parameter. Am I missing something obvious here? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- 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 i4LId5BF033420; Fri, 21 May 2004 11:39:05 -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 i4LId51t033411; Fri, 21 May 2004 11:39:05 -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 i4LId3rK033337 for ; Fri, 21 May 2004 11:39:03 -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 i4LId4Kl043778; Fri, 21 May 2004 18:39:04 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040521113626.04843bb8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 21 May 2004 11:38:57 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Pending changes to the base SASL document Cc: Jeffrey Hutzelman , Rob Siemborski , Alexey Melnikov , SASL WG In-Reply-To: References: <40ABCB09.4080102@isode.com> <3029810000.1085161453@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:54 AM 5/21/2004, Sam Hartman wrote: >>>>>> "Jeffrey" == Jeffrey Hutzelman writes: > > > Jeffrey> I also like this text more, except the use of 'should' > Jeffrey> instead of SHOULD. Using requirements keywords in lower > Jeffrey> case is confusing -- a future reader will have no way to > Jeffrey> know in which sense the word was used. > >I did not mean SHOULD. Assuming the working group believes text in >this area is appropriate, I wouldn't object to rephrasing. I prefer "should". I view the suggested text as stating a consideration not a requirement. 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 i4LIa0b4032728; Fri, 21 May 2004 11:36:00 -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 i4LIa0bd032727; Fri, 21 May 2004 11:36:00 -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 i4LIa0ND032720 for ; Fri, 21 May 2004 11:36:00 -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 i4LIa1Kl043764; Fri, 21 May 2004 18:36:01 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040521111921.0493f458@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 21 May 2004 11:35:53 -0700 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: Pending changes to the base SASL document Cc: Alexey Melnikov , SASL WG In-Reply-To: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:14 AM 5/21/2004, Rob Siemborski wrote: >On Fri, 21 May 2004, Kurt D. Zeilenga wrote: >>The problem is that RFC 2222 was terrible clear as to who the option >>for initial/final data belongs to. It seems clear that we have some >>mechanisms designers who treated it as their option and some protocol >>designers who treated it as their option. So, who's option is it? > >My interpretation of 2222 was that: > >* it was optional for a protocol profile to support the capability >* it was optional for a mechanism to support the capabilitiy (e.g. the > server might always have to send first, thus no matter what you do you > cannot use an initial client send with this mechanism) >* it was optional for the client to choose to use the capability, even if > the above two were true. The problem I have with your interpretation is that it implies that in all cases that the client always has the option to not to provide an initial response. However, RFC2222 clearly didn't provide this option in EXTERNAL. RFC 2222 was reasonable clear that an no initial response data was equivalent to empty initial response data in regards to EXTERNAL (see examples). 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 i4LIEd5N028420; Fri, 21 May 2004 11:14:39 -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 i4LIEdSW028419; Fri, 21 May 2004 11:14:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LIEcke028412 for ; Fri, 21 May 2004 11:14:38 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LIEf0s019517; Fri, 21 May 2004 14:14:41 -0400 Date: Fri, 21 May 2004 14:14:41 -0400 (EDT) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <6.0.1.1.0.20040521105853.0483ca98@127.0.0.1> Message-ID: 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 21 May 2004, Kurt D. Zeilenga wrote: > The problem is that RFC 2222 was terrible clear as to who the option > for initial/final data belongs to. It seems clear that we have some > mechanisms designers who treated it as their option and some protocol > designers who treated it as their option. So, who's option is it? My interpretation of 2222 was that: * it was optional for a protocol profile to support the capability * it was optional for a mechanism to support the capabilitiy (e.g. the server might always have to send first, thus no matter what you do you cannot use an initial client send with this mechanism) * it was optional for the client to choose to use the capability, even if the above two were true. So, I'd answer your question as "it's everyone's option except the server's" -- or rather, any one of (mechanism, protocol, client) can choose not to use the initial response for whatever reason they deem appropriate. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- 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 i4LIBGni027841; Fri, 21 May 2004 11:11: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 i4LIBGu1027840; Fri, 21 May 2004 11:11: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 i4LIBGHo027834 for ; Fri, 21 May 2004 11:11: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 i4LIBIKl043609; Fri, 21 May 2004 18:11:18 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040521105853.0483ca98@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 21 May 2004 11:11:11 -0700 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: Pending changes to the base SASL document Cc: Alexey Melnikov , SASL WG In-Reply-To: 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> 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: The problem is that RFC 2222 was terrible clear as to who the option for initial/final data belongs to. It seems clear that we have some mechanisms designers who treated it as their option and some protocol designers who treated it as their option. So, who's option is it? 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 i4LI1WON026048; Fri, 21 May 2004 11:01:32 -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 i4LI1WDe026047; Fri, 21 May 2004 11:01:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LI1WeU026039 for ; Fri, 21 May 2004 11:01:32 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MX6.andrew.cmu.edu (MX6.andrew.cmu.edu [128.2.10.116]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LI1Y0s019490; Fri, 21 May 2004 14:01:34 -0400 Date: Fri, 21 May 2004 14:01:36 -0400 (EDT) From: Rob Siemborski To: Sam Hartman cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: Message-ID: References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 flexability), then we should just forbid empty success data -- this would lead to the less confusion than attributing two potential meanings to "no success data". -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- 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 i4LHxNDa025550; Fri, 21 May 2004 10:59:23 -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 i4LHxNnL025549; Fri, 21 May 2004 10:59:23 -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 i4LHxNnj025543 for ; Fri, 21 May 2004 10:59:23 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 54436151D5C; Fri, 21 May 2004 13:59:26 -0400 (EDT) To: Alexey Melnikov Cc: 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> From: Sam Hartman Date: Fri, 21 May 2004 13:59:26 -0400 In-Reply-To: <40AE1E8B.1030708@isode.com> (Alexey Melnikov's message of "Fri, 21 May 2004 16:21:47 +0100") 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: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> Rob Siemborski wrote: >> On Thu, 20 May 2004, Alexey Melnikov wrote: >>> P.S. You haven't answered the most difficult question (# >>> 1). As you are the one who has raised the original objection, >>> I would like to hear your comments. >> Do we really need to make lack-of-response equivalent with the >> empty response? Alexey> Maybe we don't. But some of the existing LDAP Alexey> implementations treat missing additional data as no data, Alexey> and some that treat missing additional data as empty Alexey> data. There is an interoperability problem here. >> 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. 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 i4LHxIms025523; Fri, 21 May 2004 10:59:18 -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 i4LHxI56025522; Fri, 21 May 2004 10:59:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LHxHRj025516 for ; Fri, 21 May 2004 10:59:17 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MX6.andrew.cmu.edu (MX6.andrew.cmu.edu [128.2.10.116]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LHxIaf019084; Fri, 21 May 2004 13:59:18 -0400 Date: Fri, 21 May 2004 13:59:20 -0400 (EDT) From: Rob Siemborski To: Sam Hartman cc: Jeffrey Hutzelman , Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: Message-ID: References: <40ABCB09.4080102@isode.com> <3029810000.1085161453@minbar.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 21 May 2004, Sam Hartman wrote: > Jeffrey> I also like this text more, except the use of 'should' > Jeffrey> instead of SHOULD. Using requirements keywords in lower > Jeffrey> case is confusing -- a future reader will have no way to > Jeffrey> know in which sense the word was used. > > I did not mean SHOULD. Assuming the working group believes text in > this area is appropriate, I wouldn't object to rephrasing. Text in this area may be appropriate, but it seems like it opens the door to recommendations like: "SASL may be used on low bandwidth devices, thus mechanisms should[SHOULD] use as few octets as possible in their challenges and responses" "SASL may be used over high-latency links or users who type passwords slowly, thus mechanisms should[SHOULD] not be susceptible to long delays between challenges and responses" Reducing the number of round trips is indeed a noble engineering goal, but is this really a *requirement* that the base document needs to specify, or is it just good engineering practice that we can assume that the future mechanism authors will address? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- 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 i4LHt59J024737; Fri, 21 May 2004 10:55:05 -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 i4LHt5Xm024736; Fri, 21 May 2004 10:55:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LHt4Av024728 for ; Fri, 21 May 2004 10:55:04 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MX6.andrew.cmu.edu (MX6.andrew.cmu.edu [128.2.10.116]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LHt70s019475; Fri, 21 May 2004 13:55:07 -0400 Date: Fri, 21 May 2004 13:55:08 -0400 (EDT) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <6.0.1.1.0.20040521103442.049371d8@127.0.0.1> Message-ID: 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 21 May 2004, Kurt D. Zeilenga wrote: > At 10:03 AM 5/21/2004, Kurt D. Zeilenga wrote: > >That is, with this change, we need to be clear that the > >optional data features are only usable where the data to > >be transferred has non-zero length. > > And, we should note that some mechanisms may mandate > use of initial response data (and/or final data). > For instance, EXTERNAL effectively does. There is no > defined challenge, and even there was, the client's > initial message, when data provided had no length, > would be ambiguous as whether it was providing an > empty authzid or providing no initial data. So, > with EXTERNAL, initial data is not optional. This is precisely why protocols profiles need to provide "how do I send an empty challenge" information. Saying EXTERNAL makes initial data mandatory leads to ambiguity, especially with a protocol that was originally designed without an initial response, but later one is added via capability (e.g. draft-siemborski-imap-sasl-initial-response). In this case, the (new) server can only determine if the client is old-style or new-style based on if the client explicitly transmits an empty string with the initial response. Otherwise, the server *has* to assume that the client is old-style, and treat it accordingly. If "initial response is mandatory for EXTERNAL" the server can no longer make this determination. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- 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 i4LHs43h024535; Fri, 21 May 2004 10:54: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 i4LHs4lR024534; Fri, 21 May 2004 10:54:04 -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 i4LHs3Ow024520 for ; Fri, 21 May 2004 10:54:04 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 0B0D8151D5C; Fri, 21 May 2004 13:54:07 -0400 (EDT) To: Jeffrey Hutzelman Cc: Rob Siemborski , Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> <3029810000.1085161453@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Fri, 21 May 2004 13:54:07 -0400 In-Reply-To: <3029810000.1085161453@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Fri, 21 May 2004 13:44:13 -0400") 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: >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> I also like this text more, except the use of 'should' Jeffrey> instead of SHOULD. Using requirements keywords in lower Jeffrey> case is confusing -- a future reader will have no way to Jeffrey> know in which sense the word was used. I did not mean SHOULD. Assuming the working group believes text in this area is appropriate, I wouldn't object to rephrasing. 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 i4LHmjJP023506; Fri, 21 May 2004 10:48:45 -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 i4LHmjnY023505; Fri, 21 May 2004 10:48:45 -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 i4LHmjQk023498 for ; Fri, 21 May 2004 10:48:45 -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 i4LHmlKl043487; Fri, 21 May 2004 17:48:47 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040521103442.049371d8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 21 May 2004 10:48:40 -0700 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: Pending changes to the base SASL document Cc: Alexey Melnikov , SASL WG In-Reply-To: <6.0.1.1.0.20040521094503.0483fe28@127.0.0.1> References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> <6.0.1.1.0.20040521094503.0483fe28@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:03 AM 5/21/2004, Kurt D. Zeilenga wrote: >That is, with this change, we need to be clear that the >optional data features are only usable where the data to >be transferred has non-zero length. And, we should note that some mechanisms may mandate use of initial response data (and/or final data). For instance, EXTERNAL effectively does. There is no defined challenge, and even there was, the client's initial message, when data provided had no length, would be ambiguous as whether it was providing an empty authzid or providing no initial data. So, with EXTERNAL, initial data is not optional. 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 i4LHiZVh022585; Fri, 21 May 2004 10:44:35 -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 i4LHiZGt022578; Fri, 21 May 2004 10:44:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4LHiYIT022552 for ; Fri, 21 May 2004 10:44:34 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa22987; 21 May 2004 13:44 EDT Date: Fri, 21 May 2004 13:44:13 -0400 From: Jeffrey Hutzelman To: Rob Siemborski , Sam Hartman cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document Message-ID: <3029810000.1085161453@minbar.fac.cs.cmu.edu> In-Reply-To: References: <40ABCB09.4080102@isode.com> 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 Friday, May 21, 2004 09:35:05 -0400 Rob Siemborski wrote: >> SASL mechanisms should be designed to minimize the number of round >> trips required because SASL is used with protocols where connections >> are short-lived. > > I like this text more (especially the use of 'should' instead of SHOULD), > but I'm still unclear why the base document needs to say anything at all > about it. I also like this text more, except the use of 'should' instead of SHOULD. Using requirements keywords in lower case is confusing -- a future reader will have no way to know in which sense the word was used. 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 i4LHBJcX015436; Fri, 21 May 2004 10:11:19 -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 i4LHBJc7015435; Fri, 21 May 2004 10:11:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LHBI2E015427 for ; Fri, 21 May 2004 10:11:18 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MX6.andrew.cmu.edu (MX6.andrew.cmu.edu [128.2.10.116]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LHBK0s019377; Fri, 21 May 2004 13:11:20 -0400 Date: Fri, 21 May 2004 13:11:21 -0400 (EDT) From: Rob Siemborski To: "Kurt D. Zeilenga" cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <6.0.1.1.0.20040521094503.0483fe28@127.0.0.1> Message-ID: References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> <6.0.1.1.0.20040521094503.0483fe28@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: On Fri, 21 May 2004, Kurt D. Zeilenga wrote: > The first part of the problem is that we have some protocols > which allow and distinguish no and empty initial/final data > and some protocols allow either no or empty and treat the > latter as equivalent to no data. > > While the obvious "fix" may be to say that no and empty data > are equivalent in the initial response and final challenge, > both meaning no data, that does raise some additional issues. > > If the appropriate initial response to a challenge was empty, > the client could not produce that response as an optional > initial response because it no longer distinguishable from > no optional initial response. Likewise for the optional final > challenge data. > > That is, with this change, we need to be clear that the > optional data features are only usable where the data to > be transferred has non-zero length. I'm pretty sure there are currently deployed clients that use the initial response with an empty string with EXTERNAL, so I think we need to continue to encourage protocol profiles to make that distinction. If we don't want to treat success data the same way, I do think that we are in a good position to just forbid empty success data outright. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- 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 i4LH3Us5013891; Fri, 21 May 2004 10:03:30 -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 i4LH3Uo9013890; Fri, 21 May 2004 10:03:30 -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 i4LH3TaX013884 for ; Fri, 21 May 2004 10:03:29 -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 i4LH3VKl043233; Fri, 21 May 2004 17:03:31 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040521094503.0483fe28@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 21 May 2004 10:03:23 -0700 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: Pending changes to the base SASL document Cc: Alexey Melnikov , SASL WG In-Reply-To: References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The first part of the problem is that we have some protocols which allow and distinguish no and empty initial/final data and some protocols allow either no or empty and treat the latter as equivalent to no data. While the obvious "fix" may be to say that no and empty data are equivalent in the initial response and final challenge, both meaning no data, that does raise some additional issues. If the appropriate initial response to a challenge was empty, the client could not produce that response as an optional initial response because it no longer distinguishable from no optional initial response. Likewise for the optional final challenge data. That is, with this change, we need to be clear that the optional data features are only usable where the data to be transferred has non-zero length. Kurt At 08:40 AM 5/21/2004, Rob Siemborski wrote: >On Fri, 21 May 2004, Alexey Melnikov wrote: > >> > If the protocol allows for optional data to be sent with success >> > notification, the protocol profile SHOULD also describe how empty >> > success data is encoded. >> >> I thought about that, but all [known to me] protocols that allow for >> additional data with success are able to send an empty additional data. >> So this phrase seems kid of redundant. > >Then it should be easy for existing protocols to comply, shouldn't it? > >> > later on in Section 4. >> > >> > Forbidding empty success data makes me less happy (its less flexible), >> > but I think its better than defining "no data" as equivalent to "the >> > empty string was sent". > >If there is a current interop problem with LDAP, this may be the safest >way to go. > >-Rob > >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Rob Siemborski | Andrew Systems Group * Research Systems Programmer >PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 >-----BEGIN GEEK CODE BLOCK---- >Version: 3.12 >GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- >M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? >------END GEEK CODE BLOCK----- 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 i4LFevkG096502; Fri, 21 May 2004 08:40: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 i4LFevWM096501; Fri, 21 May 2004 08:40:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LFeuib096495 for ; Fri, 21 May 2004 08:40:56 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from MX6.andrew.cmu.edu (MX6.andrew.cmu.edu [128.2.10.116]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LFew0s019231; Fri, 21 May 2004 11:40:58 -0400 Date: Fri, 21 May 2004 11:40:58 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <40AE1E8B.1030708@isode.com> Message-ID: References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> <40AE1E8B.1030708@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 21 May 2004, Alexey Melnikov wrote: > > If the protocol allows for optional data to be sent with success > > notification, the protocol profile SHOULD also describe how empty > > success data is encoded. > > I thought about that, but all [known to me] protocols that allow for > additional data with success are able to send an empty additional data. > So this phrase seems kid of redundant. Then it should be easy for existing protocols to comply, shouldn't it? > > later on in Section 4. > > > > Forbidding empty success data makes me less happy (its less flexible), > > but I think its better than defining "no data" as equivalent to "the > > empty string was sent". If there is a current interop problem with LDAP, this may be the safest way to go. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- 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 i4LFLnge092837; Fri, 21 May 2004 08:21:49 -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 i4LFLn0l092836; Fri, 21 May 2004 08:21:49 -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 i4LFLmLG092828 for ; Fri, 21 May 2004 08:21:48 -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; Fri, 21 May 2004 16:21:49 +0100 Message-ID: <40AE1E8B.1030708@isode.com> Date: Fri, 21 May 2004 16:21:47 +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: Rob Siemborski CC: SASL WG Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> In-Reply-To: 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 Thu, 20 May 2004, Alexey Melnikov wrote: > >> P.S. You haven't answered the most difficult question (# 1). As you >> are the one who has raised the original objection, I would like to >> hear your comments. > > Do we really need to make lack-of-response equivalent with the empty > response? Maybe we don't. But some of the existing LDAP implementations treat missing additional data as no data, and some that treat missing additional data as empty data. There is an interoperability problem here. > It seems we can handle this cleanly enough if we treat it just like > the initial response. > > e.g. > > If the protocol allows for the initial response, the > protocol profile SHOULD also describe how an empty initial response > is encoded. > > could be worded as > > If the protocol allows for optional data to be sent with success > notification, the protocol profile SHOULD also describe how empty > success data is encoded. I thought about that, but all [known to me] protocols that allow for additional data with success are able to send an empty additional data. So this phrase seems kid of redundant. > later on in Section 4. > > Forbidding empty success data makes me less happy (its less flexible), > but I think its better than defining "no data" as equivalent to "the > empty string was sent". 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 i4LE8llC078198; Fri, 21 May 2004 07:08:47 -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 i4LE8lwx078197; Fri, 21 May 2004 07:08:47 -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 i4LE8jpT078185 for ; Fri, 21 May 2004 07:08:46 -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; Fri, 21 May 2004 15:08:47 +0100 Message-ID: <40AE0D6D.1070304@isode.com> Date: Fri, 21 May 2004 15:08:45 +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: Sam Hartman CC: SASL WG Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> <40AD19AA.8050601@isode.com> <87smdu53ud.fsf@luminous.mit.edu> In-Reply-To: <87smdu53ud.fsf@luminous.mit.edu> 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: Sam Hartman wrote: >>>>>>"Alexey" == Alexey Melnikov writes: >>>>>> >>>>>> > Alexey> I am also contemplating about writing an extension to the > Alexey> GSSAPI mechanism to allow for fast reauth in 1 round trip. > >I believe you can just remove a half round trip from the GSSAPI all >the time by combining the security layer stuff with the last token. > That would be fine, unfortunately this is not a backward compatible change to the GSSAPI mechanism. When we get to discussing the GSSAPI draft, we can talk about this. 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 i4LDd6hf072325; Fri, 21 May 2004 06:39:06 -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 i4LDd6Oh072324; Fri, 21 May 2004 06:39:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LDd5Bn072314 for ; Fri, 21 May 2004 06:39:06 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LDd60s019022; Fri, 21 May 2004 09:39:06 -0400 Date: Fri, 21 May 2004 09:39:07 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <40AD17D5.5030109@isode.com> Message-ID: References: <40ABCB09.4080102@isode.com> <40AD17D5.5030109@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 20 May 2004, Alexey Melnikov wrote: > P.S. You haven't answered the most difficult question (# 1). As you are the > one who has raised the original objection, I would like to hear your > comments. Do we really need to make lack-of-response equivilent with the empty response? It seems we can handle this cleanly enough if we treat it just like the initial response. e.g. If the protocol allows for the initial response, the protocol profile SHOULD also describe how an empty initial response is encoded. could be worded as If the protocol allows for optional data to be sent with success notifiation, the protocol profile SHOULD also describe how empty success data is encoded. later on in Section 4. Forbidding empty success data makes me less happy (its less flexible), but I think its better than defining "no data" as equivilent to "the empty string was sent". -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- 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 i4LDZ4Vi071116; Fri, 21 May 2004 06:35: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 i4LDZ48g071115; Fri, 21 May 2004 06:35:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LDZ3pV071101 for ; Fri, 21 May 2004 06:35:03 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4LDZ5af018564; Fri, 21 May 2004 09:35:05 -0400 Date: Fri, 21 May 2004 09:35:05 -0400 (EDT) From: Rob Siemborski To: Sam Hartman cc: Alexey Melnikov , SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: Message-ID: References: <40ABCB09.4080102@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 20 May 2004, Sam Hartman wrote: > How about: > > SASL mechanisms should be designed to minimize the number of round > trips required because SASL is used with protocols where connections > are short-lived. I like this text more (especially the use of 'should' instead of SHOULD), but I'm still unclear why the base document needs to say anything at all about it. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- 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 i4LD3gS5064068; Fri, 21 May 2004 06:03: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 i4LD3fBN064067; Fri, 21 May 2004 06:03:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LD3e52064053 for ; Fri, 21 May 2004 06:03:41 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id B52A276662; Fri, 21 May 2004 09:04:10 -0400 (EDT) To: Alexey Melnikov Cc: SASL WG , Rob Siemborski Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> <40AD19AA.8050601@isode.com> From: Sam Hartman Date: Fri, 21 May 2004 09:04:10 -0400 In-Reply-To: <40AD19AA.8050601@isode.com> (Alexey Melnikov's message of "Thu, 20 May 2004 21:48:42 +0100") Message-ID: <87smdu53ud.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (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: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> I am also contemplating about writing an extension to the Alexey> GSSAPI mechanism to allow for fast reauth in 1 round trip. I believe you can just remove a half round trip from the GSSAPI all the time by combining the security layer stuff with the last token. 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 i4L9PV3K006513; Fri, 21 May 2004 02:25:31 -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 i4L9PV1m006512; Fri, 21 May 2004 02:25:31 -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 i4L9PUdc006499 for ; Fri, 21 May 2004 02:25:30 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust202.tnt28.lnd4.gbr.da.uu.net [62.188.156.202]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Fri, 21 May 2004 10:25:23 +0100 Message-ID: <40AD19AA.8050601@isode.com> Date: Thu, 20 May 2004 21:48:42 +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: Sam Hartman CC: SASL WG , Rob Siemborski Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> In-Reply-To: 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: Sam Hartman wrote: >>>>>> >>>>>> >>>>>> > > Alexey> "SASL mechanisms SHOULD support fast reauthentication, > Alexey> if practical." > > Alexey> Alexey > > > > > >I don't like this text because it is not even clear what it means. > >How about: > >SASL mechanisms should be designed to minimize the number of round >trips required because SASL is used with protocols where connections >are short-lived. > Ok, that sounds better. But I will change "SASL is used" to "SASL may be used". > > >As a side note, has thought been given in the HTTP case to having >mechanisms for reusing SASL contexts across connections? > > Well, I thought about that, this is one of the reasons why I've proposed that the sentence is added. But I am not sure I have a firm opinion on how this will be done. IMHO, DIGEST-MD5 fast reauth mode can be used accross multiple connections, because the client IP is not used in the authentication exchange. I am also contemplating about writing an extension to the GSSAPI mechanism to allow for fast reauth in 1 round trip. 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 i4L9P4TA006295; Fri, 21 May 2004 02:25: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 i4L9P4Qs006294; Fri, 21 May 2004 02:25:04 -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 i4L9P3Tc006200 for ; Fri, 21 May 2004 02:25:03 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust202.tnt28.lnd4.gbr.da.uu.net [62.188.156.202]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Fri, 21 May 2004 10:24:51 +0100 Message-ID: <40AD17D5.5030109@isode.com> Date: Thu, 20 May 2004 21:40:53 +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: Rob Siemborski CC: SASL WG Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> In-Reply-To: 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 Wed, 19 May 2004, Alexey Melnikov wrote: > >> 3). Some people are complaining that some SASL mechanisms use too >> many roundtrips. This is a performance penalty for protocols like >> HTTP, where the client can reconnect multiple times. Currently only >> DIGEST-MD5 and SRP have support for fast reautentication. So, I would >> like to add the following requirement to Section 5. ("Mechanism >> profile guidelines"). Please, let me know if you agree or disagree. >> Suggested text: >> >> "SASL mechanisms SHOULD support fast reauthentication, if practical." > > > Given our limited experience with actual deployment of fast > reauthentication mechanisms (Has anyone actually tested any sort of > interoperability of DIGEST-MD5 fast reauth?), I wouldn't want us to > give the impression that a mechanism that does not support fast > reauthentication is somehow less than fully compliant (yeah, ok, it is > only a SHOULD). > > If there's a demand for mechanisms that support fast reauth, then > those mechanisms will be written and implemented widely. Currently, > that isn't the case, and I don't see a reason why the base document > needs to pass judgment on the matter. Ok, this is a fair argument against the suggested text. Alexey P.S. You haven't answered the most difficult question (# 1). As you are the one who has raised the original objection, I would like to hear your comments. 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 i4KI5FvI097459; Thu, 20 May 2004 11:05:15 -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 i4KI5Fs1097458; Thu, 20 May 2004 11:05:15 -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 i4KI5Fw6097452 for ; Thu, 20 May 2004 11:05:15 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 31112151D5C; Thu, 20 May 2004 14:05:18 -0400 (EDT) To: Alexey Melnikov Cc: SASL WG , Rob Siemborski Subject: Re: Pending changes to the base SASL document References: <40ABCB09.4080102@isode.com> From: Sam Hartman Date: Thu, 20 May 2004 14:05:17 -0400 In-Reply-To: <40ABCB09.4080102@isode.com> (Alexey Melnikov's message of "Wed, 19 May 2004 22:00:57 +0100") 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: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> "SASL mechanisms SHOULD support fast reauthentication, Alexey> if practical." Alexey> Alexey I don't like this text because it is not even clear what it means. How about: SASL mechanisms should be designed to minimize the number of round trips required because SASL is used with protocols where connections are short-lived. As a side note, has thought been given in the HTTP case to having mechanisms for reusing SASL contexts across connections? 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 i4KGg7Hs090646; Thu, 20 May 2004 09:42:07 -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 i4KGg7bX090645; Thu, 20 May 2004 09:42:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.83]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4KGg6RE090639 for ; Thu, 20 May 2004 09:42:06 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4KGg7Y8032173; Thu, 20 May 2004 12:42:07 -0400 Date: Thu, 20 May 2004 12:42:06 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: SASL WG Subject: Re: Pending changes to the base SASL document In-Reply-To: <40ABCB09.4080102@isode.com> Message-ID: References: <40ABCB09.4080102@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 19 May 2004, Alexey Melnikov wrote: > 3). Some people are complaining that some SASL mechanisms use too many > roundtrips. This is a performance penalty for protocols like HTTP, where the > client can reconnect multiple times. Currently only DIGEST-MD5 and SRP have > support for fast reautentication. So, I would like to add the following > requirement to Section 5. ("Mechanism profile guidelines"). Please, let me > know if you agree or disagree. > Suggested text: > > "SASL mechanisms SHOULD support fast reauthentication, if practical." Given our limited experience with actual deployment of fast reauthentication mechanisms (Has anyone actually tested any sort of interoperability of DIGEST-MD5 fast reauth?), I wouldn't want us to give the impression that a mechanism that does not support fast reauthentication is somehow less than fully compliant (yeah, ok, it is only a SHOULD). If there's a demand for mechanisms that support fast reauth, then those mechanisms will be written and implemented widely. Currently, that isn't the case, and I don't see a reason why the base document needs to pass judgment on the matter. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- 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 i4JNTvE1078767; Wed, 19 May 2004 16:29: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 i4JNTvB5078766; Wed, 19 May 2004 16:29:57 -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 i4JNTq65078758 for ; Wed, 19 May 2004 16:29:54 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust188.tnt5.lnd4.gbr.da.uu.net [62.188.134.188]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 20 May 2004 00:29:43 +0100 Message-ID: <40ABCB09.4080102@isode.com> Date: Wed, 19 May 2004 22:00:57 +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 , Rob Siemborski Subject: Pending changes to the base SASL document 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: I am waiting for resolution on one final issue before issuing a new revision of rfc2222bis that should be ready for Last Call. Plus I have 2 minor new issues with suggested text. 1). empty versa missing additional data with success (text in 2 places). Add to Section 4. ("Protocol profile requirements"): "Note that SASL treats an empty additional data with success notification as equivalent to no additional data with success notification. If the protocol allows for the additional data with success notification, the empty additional data SHOULD NOT be used, unless dictated otherwise by the protocol profile." I am actually not sure myself about the last sentence. Should the document just say that an empty additional data with success is prohibited? Add to Section 5. ("Mechanism profile guidelines"): "As SASL treats an empty additional data with success notification as equivalent to no additional data with success notification, mechanisms that may distinguish between no additional data and empty additional data MUST use some encoding or escape mechanism when sending data semantically equivalent to the empty additional data with success." The last sentence is awkward at best, any suggestions would be appreciated. Currently there is no SASL mechanism that make such distinction, but, IMHO, the warning should be added. ===== New issues: 2). Servers need to perform profile specific mapping from a mechanism specific authorization identity to profile specific form. The profile specific form is used internally by the server (for example for logging), but can often be used by the protocol for access control. In order for the client to determine the result of any such mapping, the protocol should have a command or option to return it to the client. For example, LDAP has 2 ways to achieve this: "Who am I" extended operation and a control that can request for mapping information to be returned upon successful authentication. I felt that this is a feature common to all protocols, and thus should be mentions in the base SASL document. Kurt suggested the following text for addition to Section 4. ("Protocol profile requirements"): Where the application-layer protocol does not precisely state how identities established through SASL relate to identities used elsewhere (e.g., access controls) in the application-layer protocol, it may be useful for the application-layer protocol to provide a facility which the client may use to discover the identity used. Any objections? 3). Some people are complaining that some SASL mechanisms use too many roundtrips. This is a performance penalty for protocols like HTTP, where the client can reconnect multiple times. Currently only DIGEST-MD5 and SRP have support for fast reautentication. So, I would like to add the following requirement to Section 5. ("Mechanism profile guidelines"). Please, let me know if you agree or disagree. Suggested text: "SASL mechanisms SHOULD support fast reauthentication, if practical." 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 i43L6lEC084210; Mon, 3 May 2004 14:06:47 -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 i43L6l6A084209; Mon, 3 May 2004 14:06:47 -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 i43L6iXm084200 for ; Mon, 3 May 2004 14:06:44 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 753A1151D5C; Mon, 3 May 2004 17:06:45 -0400 (EDT) To: Simon Josefsson Cc: ietf-sasl@imc.org Subject: Re: Use of NFKC in SASLprep References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@127.0.0.1> From: Sam Hartman Date: Mon, 03 May 2004 17:06:45 -0400 In-Reply-To: (Simon Josefsson's message of "Sat, 01 May 2004 12:43:06 +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> "Kurt D. Zeilenga" writes: >> It's my opinion that that this issue, aside from noting its >> existence, should be addressed in NFKC by the UTC, then in >> Stringprep by the IETF, and lastly in SASLprep by this WG. But >> we shouldn't wait for this, we should publish what we have as >> being "good enough" and then revise once the upstream >> specifications have been appropriately revised. Simon> Without qualifying this, this means abandoning the Simon> invariant SASLprep2(SASLprep(X)) = SASLprep(X), and given Simon> the details of PR-29 even abandoning SASLprep(SASLprep(X)) Simon> = SASLprep(X), in a few cases. In an earlier discussion Simon> about SASLprep the argument was, as far as I can recall, Simon> that my proposed text regarding storing SASLprep strings in Simon> databases was not needed, because the invariant was implied Simon> by other specifications. I think the invariant is implied and that it is our job to assume the invariant shall be maintained regardless of whether it actually is. We should make sure the authors of stringprep know we're going forward with the assumption of this invariant and agree doing so is the right course of action. If we ever violate this invariant we should do so with the understanding that the practical consequences of assuming the invariant and violating it in the manner we actually violate it are acceptable. Another point to consider regarding this issue: the IDN working group set an interesting precedent by choosing not to correct UNicode bugs in their working group. They decided they were not qualified to do so and the IETF was not the appropriate forum. If we choose to take a different course of action, we should have strong justification for why their reasoning does not apply to our circumstance. --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 i43HoGUK041892; Mon, 3 May 2004 10:50: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 i43HoGjF041891; Mon, 3 May 2004 10:50:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i43HoGJl041862 for ; Mon, 3 May 2004 10:50:16 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i43Ho46b026887; Mon, 3 May 2004 10:50:04 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i43Ho44F023163; Mon, 3 May 2004 11:50:04 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i43HnQhf010806; Mon, 3 May 2004 12:49:26 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i43HnPFO010805; Mon, 3 May 2004 12:49:25 -0500 (CDT) Date: Mon, 3 May 2004 12:49:24 -0500 From: Nicolas Williams To: Jeffrey Altman Cc: ietf-sasl@imc.org Subject: Re: Use of NFKC in SASLprep Message-ID: <20040503174924.GO9637@binky.central.sun.com> Mail-Followup-To: Jeffrey Altman , ietf-sasl@imc.org References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@127.0.0.1> <6.0.1.1.0.20040501074352.02c63750@127.0.0.1> <6.0.1.1.0.20040501112553.02c86970@127.0.0.1> <409514AC.9040404@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <409514AC.9040404@columbia.edu> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, May 02, 2004 at 11:33:00AM -0400, Jeffrey Altman wrote: > Has anyone asked the authors of StringPrep their opinion? > > Clearly this problem needs to be addressed not in SASLPrep > but in a revision to StringPrep as it affects all profiles > based on StringPrep. Modifying SASLPrep will only cause > more problems if the solution adopted for StringPrep is > incompatible. My take is that this is easy to fix in Unicode itself, as per-the recommendations in pr-29, in part because there exist Unicode implementations which do not have this problem and some that do and there's no better place to fix this than in Unicode where all downstream consumers of NFKC would benefit automatically. But see below. We have: - UAX #15 is internally inconsistent, - the inconsistency results in NFKC(NFKC(x) != NFKC(x) - but only for rather unrealistic instances of 'x' - which, nonetheless should cause us some concern - But some implementations don't have this problem, - and the fix to UAX #15 seems rather simple (but it's possible that there's more than meets the untrained eye...) All of which makes me think that Unicode is the right place to fix the problem and that we should wait for the Unicode consortium to issue a corrigendum or other statement before doing much of anything about this. Until then a security considerations warning about the troublesome input sequences ought to suffice, methinks. Mor importantly, rather than discuss this matter at the SASL or KRB or any other IETF WG I'd prefer to see this discussed more broadly and, if possible, get some input from the relevant area directors. Perhaps this matter should be taken up with the IETF liason to the Unicode consortium. Cheers, Nico -- 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 i42FUnBv022333; Sun, 2 May 2004 08:30:49 -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 i42FUnlV022332; Sun, 2 May 2004 08:30:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.59.238]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i42FUm9j022325 for ; Sun, 2 May 2004 08:30:49 -0700 (PDT) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i42FUoal023892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 2 May 2004 11:30:51 -0400 (EDT) Message-ID: <409514AC.9040404@columbia.edu> Date: Sun, 02 May 2004 11:33:00 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: Use of NFKC in SASLprep References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@127.0.0.1> <6.0.1.1.0.20040501074352.02c63750@127.0.0.1> <6.0.1.1.0.20040501112553.02c86970@127.0.0.1> In-Reply-To: <6.0.1.1.0.20040501112553.02c86970@127.0.0.1> Content-Type: multipart/alternative; boundary="------------020601000203090405030703" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------020601000203090405030703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >>and prohibit them in SASLprep output. >> > >How? Stringprep prohibit step is designed to prohibit on >a per code point basis. We'd effectively have to design >a new prohibit step for the algorithm. Why should that be >done in a SASLprep-specific manner? If the most appropriate >thing to do is prohibit certain sequences in the short term, >wouldn't it make better sense to update stringprep so that >all stringprep profiles do it in a like way? > >Kurt > Has anyone asked the authors of StringPrep their opinion? Clearly this problem needs to be addressed not in SASLPrep but in a revision to StringPrep as it affects all profiles based on StringPrep. Modifying SASLPrep will only cause more problems if the solution adopted for StringPrep is incompatible. Jeffrey Altman --------------020601000203090405030703 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: 
and prohibit them in SASLprep output.


How?  Stringprep prohibit step is designed to prohibit on
a per code point basis.  We'd effectively have to design
a new prohibit step for the algorithm.  Why should that be
done in a SASLprep-specific manner?  If the most appropriate
thing to do is prohibit certain sequences in the short term,
wouldn't it make better sense to update stringprep so that
all stringprep profiles do it in a like way?

Kurt
Has anyone asked the authors of StringPrep their opinion?

Clearly this problem needs to be addressed not in SASLPrep
but in a revision to StringPrep as it affects all profiles
based on StringPrep.  Modifying SASLPrep will only cause
more problems if the solution adopted for StringPrep is
incompatible.

Jeffrey Altman


--------------020601000203090405030703-- 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 i41J4CbS090540; Sat, 1 May 2004 12:04: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 i41J4CDf090539; Sat, 1 May 2004 12:04: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 i41J48KE090532 for ; Sat, 1 May 2004 12:04:09 -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 1BJzmR-0002WS-00 for ; Sat, 01 May 2004 21:04:07 +0200 Received: from h21n4c2o273.bredband.skanova.com ([217.208.171.21]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 May 2004 21:04:07 +0200 Received: from jas by h21n4c2o273.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 May 2004 21:04:07 +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, 01 May 2004 21:04:00 +0200 Lines: 27 Message-ID: References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@127.0.0.1> <6.0.1.1.0.20040501074352.02c63750@127.0.0.1> <6.0.1.1.0.20040501112553.02c86970@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: h21n4c2o273.bredband.skanova.com User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:aZnUrIp1XQoTPAqW1TmvDkT8NIQ= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: >>and prohibit them in SASLprep output. > > How? Stringprep prohibit step is designed to prohibit on > a per code point basis. We'd effectively have to design > a new prohibit step for the algorithm. Right. > Why should that be done in a SASLprep-specific manner? If the most > appropriate thing to do is prohibit certain sequences in the short > term, wouldn't it make better sense to update stringprep so that all > stringprep profiles do it in a like way? I'm not sure. It is conceivable that what makes sense for SASLprep does not make sense for Stringprep in general. If the authors responsible for the Stringprep revision think what you propose makes sense, then I would agree. (I wouldn't call that a short term solution, though.) But if not, and if they don't have another solution in mind, I believe idempotency is important enough, for security reasons, that SASLprep should fixed, instead of being published as-is. I'm told the Stringprep authors are preparing a statement on this issue, though, which might give other alternatives. 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 i41IX9ZG084116; Sat, 1 May 2004 11:33:09 -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 i41IX9DE084115; Sat, 1 May 2004 11:33:09 -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 i41IX6V6084099 for ; Sat, 1 May 2004 11:33:06 -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.10) with ESMTP id i41IWvaQ005228; Sat, 1 May 2004 18:33:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040501112553.02c86970@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 01 May 2004 11:32:53 -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.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@127.0.0.1> <6.0.1.1.0.20040501074352.02c63750@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 09:55 AM 5/1/2004, Simon Josefsson wrote: >"Kurt D. Zeilenga" writes: >> Simon, >> As you don't appear to support my suggestion, I wonder >> alternative you suggest we undertake. Wait? > >Short term: Evaluate the completeness of the problem sequences >described in PR-29, I rather leave that to the UTC. >and prohibit them in SASLprep output. How? Stringprep prohibit step is designed to prohibit on a per code point basis. We'd effectively have to design a new prohibit step for the algorithm. Why should that be done in a SASLprep-specific manner? If the most appropriate thing to do is prohibit certain sequences in the short term, wouldn't it make better sense to update stringprep so that all stringprep profiles do it in a like way? 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 i41Gu4kY077955; Sat, 1 May 2004 09:56: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 i41Gu4o5077954; Sat, 1 May 2004 09:56:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i41Gu0Fi077945 for ; Sat, 1 May 2004 09:56:04 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.11/8.12.11) with ESMTP id i41Gu01a008562 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 1 May 2004 18:56:00 +0200 To: "Kurt D. Zeilenga" Cc: ietf-sasl@imc.org Subject: Re: Use of NFKC in SASLprep References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@127.0.0.1> <6.0.1.1.0.20040501074352.02c63750@127.0.0.1> From: Simon Josefsson X-Hashcash: 0:040501:Kurt@OpenLDAP.org:06990d28147292b4 X-Hashcash: 0:040501:ietf-sasl@imc.org:25b9749496d2168a Date: Sat, 01 May 2004 18:55:55 +0200 In-Reply-To: <6.0.1.1.0.20040501074352.02c63750@127.0.0.1> (Kurt D. Zeilenga's message of "Sat, 01 May 2004 07:48:57 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (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: "Kurt D. Zeilenga" writes: > Simon, > > As you don't appear to support my suggestion, I wonder > alternative you suggest we undertake. Wait? Short term: Evaluate the completeness of the problem sequences described in PR-29, and prohibit them in SASLprep output. As I understand it, this would be sufficient to make SASLprep idempotent. A system where the user identifiers change several times after repeated use of SASLprep, i.e. non-idempotent SASLprep, is not robust and is difficult to analyze. Medium term: Describe the usage of SASLprep in detail. If necessary, it might be possible to do this even after the actual SASLprep algorithm has been published. If the invariant SASLPrep2(SASLprep(X))=SASLPrep2(X) is not written into SASLprep as a commitment to the future, I'd like to open the question of not using the AllowUnassigned flag, as removing it would simplify the SASLprep usage. It is a telling sign that, as far as I can tell, none of the current SASL mechanism documents discuss when to set the flag. If removal isn't an option, the use of the flag should be discussed in the documents. Long term: Write a requirements document based on the non-technical needs internationalized users have, and implement a solution to those requirements. My impression is that SASLprep has been driven by technical goals, with a world view centered around a StringPrep solution from the start. Hope this helps, 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 i41EnBuG063968; Sat, 1 May 2004 07:49:11 -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 i41EnBID063967; Sat, 1 May 2004 07:49:11 -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 i41En8Hs063960 for ; Sat, 1 May 2004 07:49:08 -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.10) with ESMTP id i41En1aQ003497; Sat, 1 May 2004 14:49:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040501074352.02c63750@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 01 May 2004 07:48:57 -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.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@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: Simon, As you don't appear to support my suggestion, I wonder alternative you suggest we undertake. Wait? Kurt At 03:43 AM 5/1/2004, Simon Josefsson wrote: >"Kurt D. Zeilenga" writes: > >> It's my opinion that that this issue, aside from noting its >> existence, should be addressed in NFKC by the UTC, then in >> Stringprep by the IETF, and lastly in SASLprep by this WG. >> But we shouldn't wait for this, we should publish what we >> have as being "good enough" and then revise once the upstream >> specifications have been appropriately revised. > >Without qualifying this, this means abandoning the invariant >SASLprep2(SASLprep(X)) = SASLprep(X), and given the details of PR-29 >even abandoning SASLprep(SASLprep(X)) = SASLprep(X), in a few cases. >In an earlier discussion about SASLprep the argument was, as far as I >can recall, that my proposed text regarding storing SASLprep strings >in databases was not needed, because the invariant was implied by >other specifications. I just hope everyone pushing this forward is >able to visualize the entire long-term puzzle, as I know I'm having >difficulties with the SASLprep piece. > >Another comment on PR-29: it may be that the problematic INPUT code >points to NFKC do not occur naturally, but as far as security is >concerned there is another question: the OUTPUT code points must also >not occur naturally. Otherwise, someone may be able to use >"unnatural" code points to bypass the first security perimeter, and >have the input changed (NFKC) into some "natural" code point once >inside the security system. Also, simply having NFKC(NFKC(x)) != >NFKC(x) may generate weird corner cases that could be exploited. > >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 i41AhHmM031706; Sat, 1 May 2004 03:43:17 -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 i41AhHdR031705; Sat, 1 May 2004 03:43:17 -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 i41AhCir031679 for ; Sat, 1 May 2004 03:43:13 -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 1BJrxh-00058s-00 for ; Sat, 01 May 2004 12:43:13 +0200 Received: from h21n4c2o273.bredband.skanova.com ([217.208.171.21]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 May 2004 12:43:13 +0200 Received: from jas by h21n4c2o273.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 May 2004 12:43:13 +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, 01 May 2004 12:43:06 +0200 Lines: 30 Message-ID: References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> <6.0.1.1.0.20040430094416.0498bdd8@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: h21n4c2o273.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:aYmeBz67Vuc+LT3AMpIgsaRxGZI= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > It's my opinion that that this issue, aside from noting its > existence, should be addressed in NFKC by the UTC, then in > Stringprep by the IETF, and lastly in SASLprep by this WG. > But we shouldn't wait for this, we should publish what we > have as being "good enough" and then revise once the upstream > specifications have been appropriately revised. Without qualifying this, this means abandoning the invariant SASLprep2(SASLprep(X)) = SASLprep(X), and given the details of PR-29 even abandoning SASLprep(SASLprep(X)) = SASLprep(X), in a few cases. In an earlier discussion about SASLprep the argument was, as far as I can recall, that my proposed text regarding storing SASLprep strings in databases was not needed, because the invariant was implied by other specifications. I just hope everyone pushing this forward is able to visualize the entire long-term puzzle, as I know I'm having difficulties with the SASLprep piece. Another comment on PR-29: it may be that the problematic INPUT code points to NFKC do not occur naturally, but as far as security is concerned there is another question: the OUTPUT code points must also not occur naturally. Otherwise, someone may be able to use "unnatural" code points to bypass the first security perimeter, and have the input changed (NFKC) into some "natural" code point once inside the security system. Also, simply having NFKC(NFKC(x)) != NFKC(x) may generate weird corner cases that could be exploited. Thanks, Simon