From owner-ietf-sasl Tue Apr 6 13:05:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36K5JPv077791; Tue, 6 Apr 2004 13:05:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36K5JKB077790; Tue, 6 Apr 2004 13:05:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36K5HEV077779 for ; Tue, 6 Apr 2004 13:05:18 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.20) id 1BAwox-00069T-4P for ietf-sasl@imc.org; Tue, 06 Apr 2004 22:05:19 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.30) id 1BAwov-0000V3-8N; Tue, 06 Apr 2004 22:05:17 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BAwou-0004jo-00; Tue, 6 Apr 2004 22:05:16 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: Half-anonymous authentication Date: Tue, 6 Apr 2004 22:05:16 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As far as I can tell, a SASL authentication method may make the authentication ID _or_ the authorization ID anonymous, but not the other one. Is that correct? Should it be correct? Non-anonymous authentication ID + anonymous authorization ID seems useful for the ANONYMOUS mechanism. Currently, servers that implement ANONYMOUS must make a special case to ensure that they don't give any access to apparently authenticated users who used this method. However, if ANONYMOUS sets the authorization ID to anonymous, servers will give anonymous access by default. That seems a lot safer, though whether it is a good idea or not depends on what the mechanism is intended to be used for. I suggested that some time ago, but got no response - it drowned in another subthread. OTOH, I can't think of a use for anonymous authentication ID with non-anonymous authorization ID, other than those which could just as well be fulfilled by setting the authentication ID as well. Like EXTERNAL. Don't know if that is any reason to forbid it, though. -- Hallvard From owner-ietf-sasl Tue Apr 6 13:25:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36KPkje079209; Tue, 6 Apr 2004 13:25:46 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36KPkpF079208; Tue, 6 Apr 2004 13:25:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36KPjVi079200 for ; Tue, 6 Apr 2004 13:25:45 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1BAx8l-0001QI-4E for ietf-sasl@imc.org; Tue, 06 Apr 2004 22:25:47 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.30) id 1BAx8f-00059P-1C for ietf-sasl@imc.org; Tue, 06 Apr 2004 22:25:41 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BAx8e-0004mI-00 for ietf-sasl@imc.org; Tue, 6 Apr 2004 22:25:40 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: Re: Half-anonymous authentication In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 6 Apr 2004 22:25:40 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Uh... OTOH, on second reading of rfc2222bis, I can't see that a mechanism may make either ID anonymous at all. It was just so "obvious" that it could do so, that I didn't notice that it couldn't. Anyway, is that intended? I wrote: > As far as I can tell, a SASL authentication method may make the > authentication ID _or_ the authorization ID anonymous, but not the > other one. Also a bit unfortunate wording. Of course it may make both non-anonymous (or anonymous?) too:-) -- Hallvard From owner-ietf-sasl Wed Apr 7 09:41:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37GfAc0010735; Wed, 7 Apr 2004 09:41:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37GfAr6010734; Wed, 7 Apr 2004 09:41:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-TWO-SIXTY-SEVEN.MIT.EDU [18.187.6.12]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37Gf9Su010722 for ; Wed, 7 Apr 2004 09:41:09 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id ACF3D15159C; Wed, 7 Apr 2004 12:41:04 -0400 (EDT) To: Hallvard B Furuseth Cc: ietf-sasl@imc.org Subject: Re: Half-anonymous authentication References: From: Sam Hartman Date: Wed, 07 Apr 2004 12:41:04 -0400 In-Reply-To: (Hallvard B. Furuseth's message of "Tue, 6 Apr 2004 22:25:40 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Hallvard" == Hallvard B Furuseth writes: Hallvard> Uh... OTOH, on second reading of rfc2222bis, I can't see Hallvard> that a mechanism may make either ID anonymous at all. Hallvard> It was just so "obvious" that it could do so, that I Hallvard> didn't notice that it couldn't. Anyway, is that Hallvard> intended? I believe the authorization ID of all users authenticated using the anonymous mechanism is the same. From owner-ietf-sasl Wed Apr 7 10:30:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37HUh4m014617; Wed, 7 Apr 2004 10:30:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37HUhbE014616; Wed, 7 Apr 2004 10:30:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37HUgDH014601 for ; Wed, 7 Apr 2004 10:30:43 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1BBGst-0006Ei-49; Wed, 07 Apr 2004 19:30:43 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.30) id 1BBGsq-0004Gy-Sh; Wed, 07 Apr 2004 19:30:40 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BBGsq-00009k-00; Wed, 7 Apr 2004 19:30:40 +0200 From: Hallvard B Furuseth Message-Id: To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: Half-anonymous authentication In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 7 Apr 2004 19:30:40 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: > >>>>> "Hallvard" == Hallvard B Furuseth writes: > > Hallvard> Uh... OTOH, on second reading of rfc2222bis, I can't see > Hallvard> that a mechanism may make either ID anonymous at all. > Hallvard> It was just so "obvious" that it could do so, that I > Hallvard> didn't notice that it couldn't. Anyway, is that > Hallvard> intended? > > I believe the authorization ID of all users authenticated using the > anonymous mechanism is the same. Not that I can see. However, Security Considerations refer to 'the anonymous user'. Looks like a good idea for the section which defines the mechanism. However, for SASL in general I was thinking of explicitly setting up the connection to have the same authorization or authentication ID as unauthenticated connections, not setting them to a special 'anonymous user'. The former is called 'anonymous' in LDAP. Sorry about bringing the term over here without explaining. -- Hallvard From owner-ietf-sasl Thu Apr 8 03:26:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38AQ4b3065140; Thu, 8 Apr 2004 03:26:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38AQ4Sf065139; Thu, 8 Apr 2004 03:26:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.svc-box.de ([66.111.56.110]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38AQ0Qh065132 for ; Thu, 8 Apr 2004 03:26:03 -0700 (PDT) (envelope-from list-ietf-sasl@mcmilk.de) Received: (qmail 32461 invoked by uid 101); 8 Apr 2004 10:26:01 -0000 Date: Thu, 8 Apr 2004 12:26:01 +0200 From: Tino Reichardt To: ietf-sasl@imc.org Subject: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Message-ID: <20040408102601.GA25498@mcmilk.de> Reply-To: Tino Reichardt Mail-Followup-To: Tino Reichardt , ietf-sasl@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello ietf-sasl list. First of all: my english isn't the best and I am new to this list. I think the draft 'The CRAM-MD5 SASL Mechanism' should not only specify the CRAM-MD5 mechanism. Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar and then specify also some other standard hash routines as SASL CRAM mechanisms: : CRAM-MD5 160bit: CRAM-SHA1 160bit: CRAM-RIPEMD-160 320bit: CRAM-RIPEMD-320 ps: The CRAM-SHA1 mechanism is already used by serveral servers and clients. references: [SHA1] http://www.itl.nist.gov/fipspubs/fip180-1.htm [RIPEMD] http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html -- regards, TR From owner-ietf-sasl Thu Apr 8 08:44:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38FiQC8091398; Thu, 8 Apr 2004 08:44:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38FiQZv091397; Thu, 8 Apr 2004 08:44:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38FiK4w091378 for ; Thu, 8 Apr 2004 08:44:25 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 8 Apr 2004 16:43:41 +0100 Message-ID: <40757325.80401@isode.com> Date: Thu, 08 Apr 2004 16:43:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tino Reichardt CC: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? References: <20040408102601.GA25498@mcmilk.de> In-Reply-To: <20040408102601.GA25498@mcmilk.de> 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: Tino Reichardt wrote: >Hello ietf-sasl list. > >First of all: my english isn't the best and I am new to this list. > >I think the draft 'The CRAM-MD5 SASL Mechanism' should not only >specify the CRAM-MD5 mechanism. >Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar >and then specify also some other standard hash routines as SASL CRAM >mechanisms: > >: CRAM-MD5 >160bit: CRAM-SHA1 >160bit: CRAM-RIPEMD-160 >320bit: CRAM-RIPEMD-320 > I am afraid documenting those is outside of the scope for this working group. However you can contact me offline if you want to document this/help out to document this. >ps: The CRAM-SHA1 mechanism is already used by serveral servers and > clients. > > >references: > >[SHA1] http://www.itl.nist.gov/fipspubs/fip180-1.htm >[RIPEMD] http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html > > Regards, Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ From owner-ietf-sasl Thu Apr 8 14:22:36 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38LMaLn011483; Thu, 8 Apr 2004 14:22:36 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38LMaEv011482; Thu, 8 Apr 2004 14:22:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38LMWhD011473 for ; Thu, 8 Apr 2004 14:22:33 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BBgym-0002OL-00 for ; Thu, 08 Apr 2004 23:22:32 +0200 Received: from h246n3c1o299.bredband.skanova.com ([217.208.174.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Apr 2004 23:22:32 +0200 Received: from jas by h246n3c1o299.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Apr 2004 23:22:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Date: Thu, 08 Apr 2004 23:22:28 +0200 Lines: 38 Message-ID: References: <20040408102601.GA25498@mcmilk.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h246n3c1o299.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:yPsGiWO39gDyhgw2Q376kQO4L8w= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tino Reichardt writes: > I think the draft 'The CRAM-MD5 SASL Mechanism' should not only > specify the CRAM-MD5 mechanism. > Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar > and then specify also some other standard hash routines as SASL CRAM > mechanisms: > > : CRAM-MD5 > 160bit: CRAM-SHA1 > 160bit: CRAM-RIPEMD-160 > 320bit: CRAM-RIPEMD-320 For what it's worth, I'm not convinced this is a good idea. Unless there is something wrong with the authentication part of CRAM-MD5, it would only decrease interoperability if variations were added. Especially considering that a stored, non-plain, password database is not compatible across hash functions. Further, I dislike SASL mechanism families. This also applies to the new GSS-API mechanisms. It is a change compared to 2222, and it makes the generic parts of a SASL library needlessly complicated (think dynamically loading the proper SASL module based on SASL mechanism name). Still, nothing prevents you from register CRAM-SHA1 at IANA, write your own specification, and using it. But, to re-iterate, I believe it isn't useful to change the current CRAM-MD5 document into a CRAM-* family. If you need a SASL mechanism that can use other hashes, have a look at GSS-*, or perhaps KERBEROS_V5. > ps: The CRAM-SHA1 mechanism is already used by serveral servers and > clients. Do you have any pointers? Thanks, Simon From owner-ietf-sasl Fri Apr 9 00:38:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i397cQGo017086; Fri, 9 Apr 2004 00:38:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i397cQqF017085; Fri, 9 Apr 2004 00:38:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.svc-box.de ([66.111.56.110]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i397c9Vw016974 for ; Fri, 9 Apr 2004 00:38:26 -0700 (PDT) (envelope-from list-ietf-sasl@mcmilk.de) Received: (qmail 21018 invoked by uid 101); 9 Apr 2004 07:38:08 -0000 Date: Fri, 9 Apr 2004 09:38:08 +0200 From: Tino Reichardt To: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Message-ID: <20040409073807.GA15126@mcmilk.de> Reply-To: Tino Reichardt Mail-Followup-To: Tino Reichardt , ietf-sasl@imc.org References: <20040408102601.GA25498@mcmilk.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * Simon Josefsson wrote: > > Tino Reichardt writes: > > > I think the draft 'The CRAM-MD5 SASL Mechanism' should not only > > specify the CRAM-MD5 mechanism. > > Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar > > and then specify also some other standard hash routines as SASL CRAM > > mechanisms: > > > > : CRAM-MD5 > > 160bit: CRAM-SHA1 > > 160bit: CRAM-RIPEMD-160 > > 320bit: CRAM-RIPEMD-320 > > For what it's worth, I'm not convinced this is a good idea. Unless > there is something wrong with the authentication part of CRAM-MD5, it > would only decrease interoperability if variations were added. > Especially considering that a stored, non-plain, password database is > not compatible across hash functions. This is true ... can you tell me applications where contexts are stored ? > > Further, I dislike SASL mechanism families. This also applies to the > new GSS-API mechanisms. It is a change compared to 2222, and it makes > the generic parts of a SASL library needlessly complicated (think > dynamically loading the proper SASL module based on SASL mechanism > name). Do you think on a special application ? Who loads what dynamically ? Adding SHA1 + RIPEMD hash algorithms to an application isn't very complex... just see [QPASSWD]. > > Still, nothing prevents you from register CRAM-SHA1 at IANA, write > your own specification, and using it. But, to re-iterate, I believe > it isn't useful to change the current CRAM-MD5 document into a CRAM-* > family. If you need a SASL mechanism that can use other hashes, have > a look at GSS-*, or perhaps KERBEROS_V5. Okay, we need for every good hash a good draft ? > > > ps: The CRAM-SHA1 mechanism is already used by serveral servers and > > clients. > > Do you have any pointers? Not much, but since it isn't mentioned in any standard: Hamster SMTP+POP3+NNTP Server/Client: http://www.tglsoft.de/misc/hamster_en.htm Cone Mail Client: http://www.courier-mta.org/cone/cone00index.html Radius Server: http://www.freeradius.org (http://www.freeradius.org/radiusd/doc/ChangeLog) also: - courier-imapd - postfix [QPASSWD] http://www.mcmilk.de/projects/qpasswd/ -- regards, TR From owner-ietf-sasl Fri Apr 9 03:54:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39AsDgI071006; Fri, 9 Apr 2004 03:54:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39AsDMO071005; Fri, 9 Apr 2004 03:54:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39As9Fr070998 for ; Fri, 9 Apr 2004 03:54:09 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BBteD-00008m-00 for ; Fri, 09 Apr 2004 12:54:09 +0200 Received: from h246n3c1o299.bredband.skanova.com ([217.208.174.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Apr 2004 12:54:09 +0200 Received: from jas by h246n3c1o299.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Apr 2004 12:54:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Date: Fri, 09 Apr 2004 12:54:05 +0200 Lines: 103 Message-ID: References: <20040408102601.GA25498@mcmilk.de> <20040409073807.GA15126@mcmilk.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h246n3c1o299.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:LICyAxXKMJ2RG80AW0HISuHUHx8= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tino Reichardt writes: > * Simon Josefsson wrote: >> >> Tino Reichardt writes: >> >> > I think the draft 'The CRAM-MD5 SASL Mechanism' should not only >> > specify the CRAM-MD5 mechanism. >> > Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar >> > and then specify also some other standard hash routines as SASL CRAM >> > mechanisms: >> > >> > : CRAM-MD5 >> > 160bit: CRAM-SHA1 >> > 160bit: CRAM-RIPEMD-160 >> > 320bit: CRAM-RIPEMD-320 >> >> For what it's worth, I'm not convinced this is a good idea. Unless >> there is something wrong with the authentication part of CRAM-MD5, it >> would only decrease interoperability if variations were added. >> Especially considering that a stored, non-plain, password database is >> not compatible across hash functions. > This is true ... can you tell me applications where contexts are > stored ? I believe Cyrus SASL has a mode in which it doesn't store plain-text passwords, only mechanism specific contexts. I'm sure other implementations can do the same. >> Further, I dislike SASL mechanism families. This also applies to the >> new GSS-API mechanisms. It is a change compared to 2222, and it makes >> the generic parts of a SASL library needlessly complicated (think >> dynamically loading the proper SASL module based on SASL mechanism >> name). > Do you think on a special application ? Who loads what dynamically ? > Adding SHA1 + RIPEMD hash algorithms to an application isn't very > complex... just see [QPASSWD]. This was a generic comment, not specific to CRAM-*. Adding code for SHA1/RIPEMD is easy, I agree. But the code that selects the proper module to implement a specific SASL mechanism, based on a family name, will be more complicated than it was in 2222. To use GSS as an example (since there is a specification for it, so we can get into details), to be flexible the SASL library would have to recognize the "GSS-" prefix, and load e.g. libgsasl-gss.so, which in turn loads the GSS implementation, iterates over all supported GSS mechanisms (which can change over time, without the SASL library knowing about it), compute the truncated MD5 and check whether it match the GSS- string. Compare this to the 2222 approach, where you load (e.g.) libgsasl-.so and that's it. One idea for solving this problem would be to make the SASL mechanism family matter purely an IETF/IANA procedural matter, and not an intrinsic part of the SASL protocol. I mean, the GSS SASL mechanism should not imply that an implementation should go through the above procedure in order to find the proper GSS mechanism to use, but that each GSS mechanism to be used within SASL is registered as such, using the truncated MD5 as the registered name, and only after that should SASL implementations be assumed to recognize it automatically. (Of course, we can't stop implementations from recognizing non-standard SASL mechanisms, perhaps by implementing the above algorithm.) >> Still, nothing prevents you from register CRAM-SHA1 at IANA, write >> your own specification, and using it. But, to re-iterate, I believe >> it isn't useful to change the current CRAM-MD5 document into a CRAM-* >> family. If you need a SASL mechanism that can use other hashes, have >> a look at GSS-*, or perhaps KERBEROS_V5. > Okay, we need for every good hash a good draft ? Yes. Or, if 2222bis is approved with SASL mechanism families, you can write a document for the entire CRAM-* family, if you make sure it doesn't collide with CRAM-MD5. >> > ps: The CRAM-SHA1 mechanism is already used by serveral servers and >> > clients. >> >> Do you have any pointers? > Not much, but since it isn't mentioned in any standard: > > Hamster SMTP+POP3+NNTP Server/Client: > http://www.tglsoft.de/misc/hamster_en.htm > > Cone Mail Client: > http://www.courier-mta.org/cone/cone00index.html > > Radius Server: > http://www.freeradius.org > (http://www.freeradius.org/radiusd/doc/ChangeLog) > > also: > - courier-imapd > - postfix > > > [QPASSWD] http://www.mcmilk.de/projects/qpasswd/ It appears as if a document describing CRAM-SHA1 would be a useful contribution. You can add a link to it on the IANA SASL page. Regards, Simon From owner-ietf-sasl Fri Apr 9 10:45:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39HjXZ0023685; Fri, 9 Apr 2004 10:45:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39HjXlg023684; Fri, 9 Apr 2004 10:45:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.svc-box.de ([66.111.56.110]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39HjVnr023678 for ; Fri, 9 Apr 2004 10:45:32 -0700 (PDT) (envelope-from list-ietf-sasl@mcmilk.de) Received: (qmail 16831 invoked by uid 101); 9 Apr 2004 17:45:34 -0000 Date: Fri, 9 Apr 2004 19:45:34 +0200 From: Tino Reichardt To: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Message-ID: <20040409174534.GA9707@mcmilk.de> Reply-To: Tino Reichardt Mail-Followup-To: Tino Reichardt , ietf-sasl@imc.org References: <20040408102601.GA25498@mcmilk.de> <20040409073807.GA15126@mcmilk.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * Simon Josefsson wrote: > > Tino Reichardt writes: > > > * Simon Josefsson wrote: > >> > >> Tino Reichardt writes: > >> > >> > I think the draft 'The CRAM-MD5 SASL Mechanism' should not only > >> > specify the CRAM-MD5 mechanism. > >> > Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar > >> > and then specify also some other standard hash routines as SASL CRAM > >> > mechanisms: > >> > > >> > : CRAM-MD5 > >> > 160bit: CRAM-SHA1 > >> > 160bit: CRAM-RIPEMD-160 > >> > 320bit: CRAM-RIPEMD-320 > >> > >> For what it's worth, I'm not convinced this is a good idea. Unless > >> there is something wrong with the authentication part of CRAM-MD5, it > >> would only decrease interoperability if variations were added. > >> Especially considering that a stored, non-plain, password database is > >> not compatible across hash functions. > > This is true ... can you tell me applications where contexts are > > stored ? > > I believe Cyrus SASL has a mode in which it doesn't store plain-text > passwords, only mechanism specific contexts. I'm sure other > implementations can do the same. Okay, but for SMTP + POP3 servers doesn't that matter, because the initial server response differs every time ... So storing contexts here, makes no sense. As far as I know - Maybe I am on the wrong track :) > > >> Further, I dislike SASL mechanism families. This also applies to the > >> new GSS-API mechanisms. It is a change compared to 2222, and it makes > >> the generic parts of a SASL library needlessly complicated (think > >> dynamically loading the proper SASL module based on SASL mechanism > >> name). > > Do you think on a special application ? Who loads what dynamically ? > > Adding SHA1 + RIPEMD hash algorithms to an application isn't very > > complex... just see [QPASSWD]. > > This was a generic comment, not specific to CRAM-*. Adding code for > SHA1/RIPEMD is easy, I agree. > > But the code that selects the proper module to implement a specific > SASL mechanism, based on a family name, will be more complicated than > it was in 2222. To use GSS as an example (since there is a > specification for it, so we can get into details), to be flexible the > SASL library would have to recognize the "GSS-" prefix, and load > e.g. libgsasl-gss.so, which in turn loads the GSS implementation, > iterates over all supported GSS mechanisms (which can change over > time, without the SASL library knowing about it), compute the > truncated MD5 and check whether it match the GSS- string. > Compare this to the 2222 approach, where you load (e.g.) > libgsasl-.so and that's it. The applications should just load what they need to support some special typ of SASL mechanism. But such a implementation can't be the reason for not specifying new mechanisms. They have to load for every new SASL mechanism another library, when it doesn't work another way. Maybe the concept of those implementations is wrong, because when I want to by a car, I don't choose the tires first and then the car, which has to fit to them. > > One idea for solving this problem would be to make the SASL mechanism > family matter purely an IETF/IANA procedural matter, and not an > intrinsic part of the SASL protocol. I mean, the GSS SASL mechanism > should not imply that an implementation should go through the above > procedure in order to find the proper GSS mechanism to use, but that > each GSS mechanism to be used within SASL is registered as such, using > the truncated MD5 as the registered name, and only after that should > SASL implementations be assumed to recognize it automatically. (Of > course, we can't stop implementations from recognizing non-standard > SASL mechanisms, perhaps by implementing the above algorithm.) Hm... > >> Still, nothing prevents you from register CRAM-SHA1 at IANA, write > >> your own specification, and using it. But, to re-iterate, I believe > >> it isn't useful to change the current CRAM-MD5 document into a CRAM-* > >> family. If you need a SASL mechanism that can use other hashes, have > >> a look at GSS-*, or perhaps KERBEROS_V5. > > Okay, we need for every good hash a good draft ? > > Yes. Or, if 2222bis is approved with SASL mechanism families, you can > write a document for the entire CRAM-* family, if you make sure it > doesn't collide with CRAM-MD5. HMAC-SHA1 and HMAC-RIPEMD is also spcified in rfc 2104. So why shouldn't CRAM-SHA1 + CRAM-RIPEMD be mentioned in a new CRAM-MD5 rfc ? Maybe the name isn't the best one than - okay :) > It appears as if a document describing CRAM-SHA1 would be a useful > contribution. You can add a link to it on the IANA SASL page. Who? -- regards, TR From owner-ietf-sasl Fri Apr 9 11:42:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39Ig4OG029316; Fri, 9 Apr 2004 11:42:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39Ig4qA029315; Fri, 9 Apr 2004 11:42:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39Ig3ZN029309 for ; Fri, 9 Apr 2004 11:42:03 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i39Ig7Ms012047; Fri, 9 Apr 2004 18:42:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040409112800.04a86188@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 09 Apr 2004 11:41:52 -0700 To: Tino Reichardt From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Cc: ietf-sasl@imc.org In-Reply-To: <20040408102601.GA25498@mcmilk.de> References: <20040408102601.GA25498@mcmilk.de> 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: Tino, The WG CRAM-MD5 work item is limited to revising the SASL CRAM-MD5 authentication mechanism. Engineering of other CRAM-based mechanisms is simply beyond the scope of the working group. I suggest you pursue the specification of other mechanisms on an individual basis. I do not that this list is an acceptable forum for review of SASL-related submissions produced by individuals (as long as such review does not impede progress on WG deliverables). Regards, Kurt (as co-chair of the SASL-WG) At 03:26 AM 4/8/2004, Tino Reichardt wrote: >Hello ietf-sasl list. > >First of all: my english isn't the best and I am new to this list. > >I think the draft 'The CRAM-MD5 SASL Mechanism' should not only >specify the CRAM-MD5 mechanism. >Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar >and then specify also some other standard hash routines as SASL CRAM >mechanisms: > >: CRAM-MD5 >160bit: CRAM-SHA1 >160bit: CRAM-RIPEMD-160 >320bit: CRAM-RIPEMD-320 > > >ps: The CRAM-SHA1 mechanism is already used by serveral servers and > clients. > > >references: > >[SHA1] http://www.itl.nist.gov/fipspubs/fip180-1.htm >[RIPEMD] http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html > > >-- >regards, TR From owner-ietf-sasl Fri Apr 9 12:41:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39Jfr6j036742; Fri, 9 Apr 2004 12:41:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39JfrPb036741; Fri, 9 Apr 2004 12:41:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39JfqjA036735 for ; Fri, 9 Apr 2004 12:41:52 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i39JfvMs013115; Fri, 9 Apr 2004 19:41:57 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040409124008.04a88ab0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 09 Apr 2004 12:41:41 -0700 To: Tino Reichardt From: "Kurt D. Zeilenga" Subject: [corrected] Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Cc: ietf-sasl@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: My previous note had a few unfortunate typos in it. This should be more clear. Sorry for any confusion. -- Kurt Tino, The SASL WG's CRAM-MD5 work item is limited to revising the SASL CRAM-MD5 authentication mechanism. Engineering of other CRAM-based mechanisms is simply beyond the scope of this working group. I suggest you pursue the specification of other mechanisms on an individual basis. I do note that this list is an acceptable forum for review of SASL-related submissions produced by individuals (as long as such review does not impede progress on WG deliverables). Regards, Kurt (as co-chair of the SASL-WG) At 03:26 AM 4/8/2004, Tino Reichardt wrote: >Hello ietf-sasl list. > >First of all: my english isn't the best and I am new to this list. > >I think the draft 'The CRAM-MD5 SASL Mechanism' should not only >specify the CRAM-MD5 mechanism. >Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar >and then specify also some other standard hash routines as SASL CRAM >mechanisms: > >: CRAM-MD5 >160bit: CRAM-SHA1 >160bit: CRAM-RIPEMD-160 >320bit: CRAM-RIPEMD-320 > > >ps: The CRAM-SHA1 mechanism is already used by serveral servers and > clients. > > >references: > >[SHA1] http://www.itl.nist.gov/fipspubs/fip180-1.htm >[RIPEMD] http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html > > >-- >regards, TR From owner-ietf-sasl Fri Apr 9 13:29:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39KTqXi042019; Fri, 9 Apr 2004 13:29:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39KTq0f042018; Fri, 9 Apr 2004 13:29:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.svc-box.de ([66.111.56.110]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39KToYJ042010 for ; Fri, 9 Apr 2004 13:29:51 -0700 (PDT) (envelope-from list-ietf-sasl@mcmilk.de) Received: (qmail 32135 invoked by uid 101); 9 Apr 2004 20:29:54 -0000 Date: Fri, 9 Apr 2004 22:29:54 +0200 From: Tino Reichardt To: ietf-sasl@imc.org Subject: Re: [corrected] Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Message-ID: <20040409202954.GA30779@mcmilk.de> Reply-To: Tino Reichardt Mail-Followup-To: Tino Reichardt , ietf-sasl@imc.org References: <6.0.1.1.0.20040409124008.04a88ab0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.1.1.0.20040409124008.04a88ab0@127.0.0.1> User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * "Kurt D. Zeilenga" wrote: > > My previous note had a few unfortunate typos in it. This should be > more clear. Sorry for any confusion. -- Kurt No problem :) > Tino, > > The SASL WG's CRAM-MD5 work item is limited to revising the SASL > CRAM-MD5 authentication mechanism. Engineering of other CRAM-based > mechanisms is simply beyond the scope of this working group. I > suggest you pursue the specification of other mechanisms on an > individual basis. Okay, I will do so. > > I do note that this list is an acceptable forum for review of > SASL-related submissions produced by individuals (as long as > such review does not impede progress on WG deliverables). Sorry, if I was to pertly :) -- regards, TR From owner-ietf-sasl Fri Apr 9 13:37:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39Kbcmv042828; Fri, 9 Apr 2004 13:37:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39Kbccp042827; Fri, 9 Apr 2004 13:37:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39KbXWA042813 for ; Fri, 9 Apr 2004 13:37:34 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BC2ks-0003Pn-00 for ; Fri, 09 Apr 2004 22:37:38 +0200 Received: from h246n3c1o299.bredband.skanova.com ([217.208.174.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Apr 2004 22:37:38 +0200 Received: from jas by h246n3c1o299.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Apr 2004 22:37:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Date: Fri, 09 Apr 2004 22:37:33 +0200 Lines: 49 Message-ID: References: <20040408102601.GA25498@mcmilk.de> <20040409073807.GA15126@mcmilk.de> <20040409174534.GA9707@mcmilk.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h246n3c1o299.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:w3uSLJKW9MRW3uxSLUDknYXVXV4= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tino Reichardt writes: >> But the code that selects the proper module to implement a specific >> SASL mechanism, based on a family name, will be more complicated than >> it was in 2222. To use GSS as an example (since there is a >> specification for it, so we can get into details), to be flexible the >> SASL library would have to recognize the "GSS-" prefix, and load >> e.g. libgsasl-gss.so, which in turn loads the GSS implementation, >> iterates over all supported GSS mechanisms (which can change over >> time, without the SASL library knowing about it), compute the >> truncated MD5 and check whether it match the GSS- string. >> Compare this to the 2222 approach, where you load (e.g.) >> libgsasl-.so and that's it. > > The applications should just load what they need to support some > special typ of SASL mechanism. But such a implementation can't be the > reason for not specifying new mechanisms. Right, the argument was a reason for not introducing SASL mechanism families at all, at least not as a protocol matter, in 2222bis. Don't take it as criticism of your idea specifically, it wasn't meant as such. Your idea just made me think of the general topic of SASL mechanism families. >> Yes. Or, if 2222bis is approved with SASL mechanism families, you can >> write a document for the entire CRAM-* family, if you make sure it >> doesn't collide with CRAM-MD5. > > HMAC-SHA1 and HMAC-RIPEMD is also spcified in rfc 2104. So why > shouldn't CRAM-SHA1 + CRAM-RIPEMD be mentioned in a new CRAM-MD5 rfc ? > Maybe the name isn't the best one than - okay :) As Kurt Zeilenga said, the agenda for CRAM-MD5 is rather limited. Delaying it further because it can be generalized, does not sound like a good idea to me. This doesn't mean you can't work on CRAM-* in parallel though, and since you quoted existing software that uses it, having it documented and registered with IANA would be a good idea. The document for CRAM-* could begin by explaining what the technical motivations for developing it was. At least I'm curious about that. (Don't you trust MD5? Is the code size of MD5 too large? Etc.) >> It appears as if a document describing CRAM-SHA1 would be a useful >> contribution. You can add a link to it on the IANA SASL page. > Who? See http://www.iana.org/assignments/sasl-mechanisms Regards, Simon From owner-ietf-sasl Fri Apr 9 13:53:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39KruoU044565; Fri, 9 Apr 2004 13:53:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39Kru6T044564; Fri, 9 Apr 2004 13:53:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39KrtTp044557 for ; Fri, 9 Apr 2004 13:53:55 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i39KrsMs014616; Fri, 9 Apr 2004 20:53:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040409134944.04aa9da0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 09 Apr 2004 13:53:39 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Family of mechanism (Was: draft-ietf-sasl-crammd5-02 / additional mechanisms ?) Cc: ietf-sasl@imc.org In-Reply-To: References: <20040408102601.GA25498@mcmilk.de> <20040409073807.GA15126@mcmilk.de> 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:54 AM 4/9/2004, Simon Josefsson wrote: >One idea for solving this problem would be to make the SASL mechanism >family matter purely an IETF/IANA procedural matter, and not an >intrinsic part of the SASL protocol. It should be clear in the revised SASL base specification, if not already so, that families of mechanisms is purely a name space matter. To the protocol, each name/mechanism is independent of all other name/mechanism pairs. Kurt From owner-ietf-sasl Fri Apr 9 17:06:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3A06RtD066022; Fri, 9 Apr 2004 17:06:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3A06RCQ066021; Fri, 9 Apr 2004 17:06:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3A06QFN066015 for ; Fri, 9 Apr 2004 17:06:26 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3A06VMs017628; Sat, 10 Apr 2004 00:06:32 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 09 Apr 2004 17:06:16 -0700 To: Sam Hartman , Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication 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 09:41 AM 4/7/2004, Sam Hartman wrote: >>>>>> "Hallvard" == Hallvard B Furuseth writes: > > Hallvard> Uh... OTOH, on second reading of rfc2222bis, I can't see > Hallvard> that a mechanism may make either ID anonymous at all. > Hallvard> It was just so "obvious" that it could do so, that I > Hallvard> didn't notice that it couldn't. Anyway, is that > Hallvard> intended? > >I believe the authorization ID of all users authenticated using the >anonymous mechanism is the same. "users authenticated using the anonymous mechanism", I think, is a odd phrase. The anonymous mechanism doesn't provide any authentication service. (Not all SASL mechanisms provide authentication services.) I also find it odd the implication (in Hallvard's comments) that an anonymous user has an established identity. I take the view that an anonymous user is one whose's identity has not been established (or is concealed). While some implementations (and maybe even some application protocols) might associate a particular identity representation to users who are anonymous (have no established identity), this by no means implies that anonymous mechanism establishes (authenticates) the identity of the user. It doesn't. Hallvard: I'm not sure what your question is (in your last response). If your asking whether SASL itself or the ANONYMOUS mechanism defines a particular identity representation to refer to anonymous users (users which have no established identity), I think the answer is no. If your asking whether SASL or ANONYMOUS explicitly provides a facility for a user to authenticate oneself and assume the authorization of an anonymous user, I think the answer is no. I note, nothing explicitly prevents application protocol specifications from providing such facilities, including by means of defining a particular identity representation to refer to users who have not established their identity. Kurt From owner-ietf-sasl Sat Apr 10 07:54:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AEs4vF039535; Sat, 10 Apr 2004 07:54:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AEs4mw039534; Sat, 10 Apr 2004 07:54:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AEs3GN039517 for ; Sat, 10 Apr 2004 07:54:03 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1BCJrq-0001j9-39; Sat, 10 Apr 2004 16:53:58 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.30) id 1BCJrm-0005NS-PM; Sat, 10 Apr 2004 16:53:54 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BCJrl-0002SW-00; Sat, 10 Apr 2004 16:53:53 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Sam Hartman , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication In-Reply-To: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sat, 10 Apr 2004 16:53:53 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >At 09:41 AM 4/7/2004, Sam Hartman wrote: > >>>>>>> "Hallvard" == Hallvard B Furuseth writes: >> >> Hallvard> Uh... OTOH, on second reading of rfc2222bis, I can't see >> Hallvard> that a mechanism may make either ID anonymous at all. >> Hallvard> It was just so "obvious" that it could do so, that I >> Hallvard> didn't notice that it couldn't. Anyway, is that >> Hallvard> intended? >> >>I believe the authorization ID of all users authenticated using the >>anonymous mechanism is the same. > > "users authenticated using the anonymous mechanism", I think, > is a odd phrase. The anonymous mechanism doesn't provide any > authentication service. (Not all SASL mechanisms provide > authentication services.) That's not what rfc2222bis says. It describes SASL mechanisms as authentication mechanisms, and describes everything about these in terms of authentication. So according to rfc2222bis, ANONYMOUS is an authentication mechanism. One which doesn't authenticate, from what you say. (BTW, note the command 'A002 AUTHENTICATE ANONYMOUS' in the example in the ANONYMOUS draft.) Anyway, at first I thought this meant the identity sent with ANONYMOUS had to be the authentication ID, but I now notice that this is wrong. However, I think the ANONYMOUS draft does need to say explicitly how it affects the authentication and authorization IDs. Also, I now wonder how clients typically implement ANONYMOUS. If they support several SASL mechanisms, do clients expect the identity to send with ANONYMOUS in the same command line option or whatever which they use for the authentication IDs for other SASL mechanisms, or do they use some other field? Anyway, > I also find it odd the implication (in Hallvard's comments) that an > anonymous user has an established identity. I take the view that an > anonymous user is one whose's identity has not been established See above. Also, Sam's statement that all ANONYMOUS users have the _same_ authorization ID, not _no_ authorization ID. Which made me realize that anonymous auth is not a SASL term, but one I'm used to from LDAP, where it means the same as no auth. OTOH, FTP (at least on Unix) implements anonymous auth the way Sam describes: A specific user on the server's system, with limited access. > (or is concealed). Oh dear. I wish you hadn't added that. Which identity do you mean? Authentication or authorization identity, after all? And who is it concealed from? The server, or other users? > Hallvard: I'm not sure what your question is (in your last > response). If your asking whether SASL itself or the > ANONYMOUS mechanism defines a particular identity representation > to refer to anonymous users (users which have no established > identity), I think the answer is no. If your asking whether > SASL or ANONYMOUS explicitly provides a facility for a user > to authenticate oneself and assume the authorization of an > anonymous user, I think the answer is no. Almost... I'm wondering if SASL even allows an authentication mechanism to revert the authentication and authorization IDs back to unauthenticated - that is, the same state as before the first authentication. But perhaps it would be problematic if the did, since it would mess up for protocols that require authentication. Maybe an 'anonymous user' is a better concept, which protocols can treat either the same way as unauthenticated or as a normal user with limited access. > I note, nothing explicitly prevents application protocol > specifications from providing such facilities, including > by means of defining a particular identity representation > to refer to users who have not established their identity. -- Hallvard From owner-ietf-sasl Sat Apr 10 09:13:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AGDuLo050600; Sat, 10 Apr 2004 09:13:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AGDuRv050599; Sat, 10 Apr 2004 09:13:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AGDteF050593 for ; Sat, 10 Apr 2004 09:13:55 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3AGDwMs032505; Sat, 10 Apr 2004 16:13:58 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 10 Apr 2004 09:12:40 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication Cc: Sam Hartman , ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@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 07:53 AM 4/10/2004, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>At 09:41 AM 4/7/2004, Sam Hartman wrote: >> >>>>>>>> "Hallvard" == Hallvard B Furuseth writes: >>> >>> Hallvard> Uh... OTOH, on second reading of rfc2222bis, I can't see >>> Hallvard> that a mechanism may make either ID anonymous at all. >>> Hallvard> It was just so "obvious" that it could do so, that I >>> Hallvard> didn't notice that it couldn't. Anyway, is that >>> Hallvard> intended? >>> >>>I believe the authorization ID of all users authenticated using the >>>anonymous mechanism is the same. >> >> "users authenticated using the anonymous mechanism", I think, >> is a odd phrase. The anonymous mechanism doesn't provide any >> authentication service. (Not all SASL mechanisms provide >> authentication services.) > >That's not what rfc2222bis says. It describes SASL mechanisms as >authentication mechanisms, and describes everything about these in terms >of authentication. Which is a problem. rfc2222bis should be likely use more generic terms, like "SASL mechanism" when referring to a SASL mechanism. >So according to rfc2222bis, ANONYMOUS is an authentication mechanism. rfc2222bis shouldn't imply that all SASL mechanisms provide authentication services. >One which doesn't authenticate, from what you say. I would hope it obvious that ANONYMOUS does not authenticate anything. >Anyway, at first I thought this meant the identity sent with ANONYMOUS >had to be the authentication ID, but I now notice that this is wrong. The only information ANONYMOUS transfers is for trace purposes. It has no semantical value to the mechanism. >However, I think the ANONYMOUS draft does need to say explicitly how it >affects the authentication and authorization IDs. How any mechanism affects authentication and authorization IDs outside of the mechanism is beyond the scope of that mechanism. It should be obvious that this mechanism does not itself establish an authentication identity nor transfer an authorization identity. However, if more clarity is needed, I would suggest replacing the paragraph: This mechanism does not provide a security layer. with: This mechanism does not establish the identity of the client (or user) nor the server (or service); does not support transfer of an authorization identity; nor provide a security layer. and relocate this paragraph more towards the top of the section. >Also, I now wonder how clients typically implement ANONYMOUS. If they >support several SASL mechanisms, do clients expect the identity to send >with ANONYMOUS in the same command line option or whatever which they >use for the authentication IDs for other SASL mechanisms, or do they use >some other field? I suggest you look at some existing implementations. But I would hope the user would not be asked or expected to provide their credentials (or portions of their credentials) when using this mechanism. >Anyway, > >> I also find it odd the implication (in Hallvard's comments) that an >> anonymous user has an established identity. I take the view that an >> anonymous user is one whose's identity has not been established > >See above. Also, Sam's statement that all ANONYMOUS users have the >_same_ authorization ID, not _no_ authorization ID. I think Sam's statement is problematic in that implies that the mechanism is establishing or authenticating the user's identity. The server might be associating an identity with anonymous users, but the server certainly is not establishing or authenticating the user's identity. >Which made me realize that anonymous auth is not a SASL term, but one I'm used to from >LDAP, where it means the same as no auth. OTOH, FTP (at least on Unix) >implements anonymous auth the way Sam describes: A specific user on the >server's system, with limited access. But it should be clear that anonymous methods in LDAP, FTP, and elsewhere are not authenticating the user's identity. >> (or is concealed). > >Oh dear. I wish you hadn't added that. RFC 2828: $ anonymous (I) The condition of having a name that is unknown or concealed. >Which identity do you mean? The identity of the user (or a user). >Authentication or authorization identity, after all? Both, as they both refer to identities of users. >And who is it concealed from? The server, or other users? In this case, they are concealed from (at least) the server. >> Hallvard: I'm not sure what your question is (in your last >> response). If your asking whether SASL itself or the >> ANONYMOUS mechanism defines a particular identity representation >> to refer to anonymous users (users which have no established >> identity), I think the answer is no. If your asking whether >> SASL or ANONYMOUS explicitly provides a facility for a user >> to authenticate oneself and assume the authorization of an >> anonymous user, I think the answer is no. > >Almost... I'm wondering if SASL even allows an authentication >mechanism to revert the authentication and authorization IDs back >to unauthenticated - that is, the same state as before the first >authentication. SASL doesn't support "revert", it supports moving to a new authorization state. That new authorization state could be an anonymous one (one where the identity of the user is not established (authenticated)). >But perhaps it would be problematic if the did, >since it would mess up for protocols that require authentication. ANONYMOUS allows protocols which previously required authentication of the user to support processing without authentication of the user. That is, it allows the "authenticate" command to be used in a fashion which doesn't actually authenticate anything. Which, BTW, >(BTW, note the command 'A002 AUTHENTICATE ANONYMOUS' in the >example in the ANONYMOUS draft.) is what's happening here. This AUTHENTICATE command does not cause anything to be authenticated. >Maybe an 'anonymous user' is a better concept, which protocols >can treat either the same way as unauthenticated or as a normal >user with limited access. > >> I note, nothing explicitly prevents application protocol >> specifications from providing such facilities, including >> by means of defining a particular identity representation >> to refer to users who have not established their identity. > >-- >Hallvard From owner-ietf-sasl Sat Apr 10 09:57:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AGvxGS056182; Sat, 10 Apr 2004 09:57:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AGvxL4056181; Sat, 10 Apr 2004 09:57:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-FIFTY-THREE.MIT.EDU [18.187.6.98]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AGvxp1056174 for ; Sat, 10 Apr 2004 09:57:59 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 90F0415159C; Sat, 10 Apr 2004 12:58:01 -0400 (EDT) To: Hallvard B Furuseth Cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> From: Sam Hartman Date: Sat, 10 Apr 2004 12:58:01 -0400 In-Reply-To: (Hallvard B. Furuseth's message of "Sat, 10 Apr 2004 16:53:53 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard> See above. Also, Sam's statement that all ANONYMOUS Hallvard> users have the _same_ authorization ID, not _no_ Hallvard> authorization ID. Which made me realize that anonymous Hallvard> auth is not a SASL term, but one I'm used to from LDAP, Hallvard> where it means the same as no auth. OTOH, FTP (at least Hallvard> on Unix) implements anonymous auth the way Sam Hallvard> describes: A specific user on the server's system, with Hallvard> limited access. I think my statement is still generally true. It may happen that the authorization ID of anonymous users is also the same as the authorization ID of users who have engaged in no authentication exchange. It may be the case (and generally is) that the authorization ID of anonymous users cannot be represented as a string transmitted over the wire. --Sam From owner-ietf-sasl Sat Apr 10 09:59:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AGxxZu056401; Sat, 10 Apr 2004 09:59:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AGxx2o056400; Sat, 10 Apr 2004 09:59:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-FIFTY-THREE.MIT.EDU [18.187.6.98]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AGxwph056394 for ; Sat, 10 Apr 2004 09:59:59 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id E78EB15159C; Sat, 10 Apr 2004 13:00:01 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> From: Sam Hartman Date: Sat, 10 Apr 2004 13:00:01 -0400 In-Reply-To: <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> (Kurt D. Zeilenga's message of "Sat, 10 Apr 2004 09:12:40 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> Which is a problem. rfc2222bis should be likely use more Kurt> generic terms, like "SASL mechanism" when referring to a Kurt> SASL mechanism. I don't tend to agree with this. IT seems that viewing anonymous authentication as authentication is a smaller change at this date than assuming not all SASL mechanisms authenticate. >From a practical standpoint, I believe they are isomorphic models. Should I would prefer to choose the model that is most consistent with our documents. --Sam From owner-ietf-sasl Sat Apr 10 10:33:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AHXcoB060233; Sat, 10 Apr 2004 10:33:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AHXc39060232; Sat, 10 Apr 2004 10:33:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AHXb2m060214 for ; Sat, 10 Apr 2004 10:33:38 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.20) id 1BCMMK-0005x6-Q8; Sat, 10 Apr 2004 19:33:36 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.30) id 1BCMMG-0002ec-6k; Sat, 10 Apr 2004 19:33:32 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BCMMF-0002pc-00; Sat, 10 Apr 2004 19:33:31 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Sam Hartman , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication In-Reply-To: <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sat, 10 Apr 2004 19:33:31 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >At 07:53 AM 4/10/2004, Hallvard B Furuseth wrote: >>Kurt D. Zeilenga writes: >>>At 09:41 AM 4/7/2004, Sam Hartman wrote: >>>>>>>>> "Hallvard" == Hallvard B Furuseth writes: >>>> >>> The anonymous mechanism doesn't provide any >>> authentication service. (Not all SASL mechanisms provide >>> authentication services.) >> >> That's not what rfc2222bis says. It describes SASL mechanisms as >> authentication mechanisms, and describes everything about these in >> terms of authentication. > > Which is a problem. rfc2222bis should be likely use more > generic terms, like "SASL mechanism" when referring to a > SASL mechanism. rfc2222 does the same thing. Did it incorrectly describe existing implementations, or were mechanisms like ANONYMOUS added later? >> One which doesn't authenticate, from what you say. > > I would hope it obvious that ANONYMOUS does not authenticate anything. If it affects the authorization or authentication IDs, it... well, un-authenticates, I suppose. If it doesn't, it seems to violate rfc2222 and rfc2222bis. >> However, I think the ANONYMOUS draft does need to say explicitly how it >> affects the authentication and authorization IDs. > > How any mechanism affects authentication and authorization IDs > outside of the mechanism is beyond the scope of that mechanism. Beyond the scope of any mechanism, I think. Correction: It needs to say which authentication and authorization IDs it _requests_. Or provides, or whatever is the correct term. Hopefully these IDs will be treated just like IDs from other SASL mechanisms. Or like no ID (unauthenticated), if that's what the mechanism requests. > It should be obvious that this mechanism does not itself > establish an authentication identity nor transfer an authorization > identity. However, if more clarity is needed, I would suggest > replacing the paragraph: > This mechanism does not provide a security layer. > with: > This mechanism does not establish the identity of the > client (or user) nor the server (or service); does not > support transfer of an authorization identity; nor > provide a security layer. I think either 'It requests anonymous authentication and authorization identities. How to treat the anonymous ID is up to the protocol or implementation.', or 'It does not affect the authentication and authorization identities'. >> Also, I now wonder how clients typically implement ANONYMOUS. If they >> support several SASL mechanisms, do clients expect the identity to send >> with ANONYMOUS in the same command line option or whatever which they >> use for the authentication IDs for other SASL mechanisms, or do they use >> some other field? > > I suggest you look at some existing implementations. I don't know where to find any... > But > I would hope the user would not be asked or expected to > provide their credentials (or portions of their credentials) > when using this mechanism. If you mean e.g. a password, I agree. However, I was thinking of clients that authenticate to the server and then grant access to something on the client side depending on whether or not authentication succeeds. Such a client must not treat the ID sent with ANONYMOUS as an authentication ID. Or it could refuse the user to specify the ANONYMOUS mechanism, of course. >>> I also find it odd the implication (in Hallvard's comments) that an >>> anonymous user has an established identity. I take the view that an >>> anonymous user is one whose's identity has not been established >> >> See above. Also, Sam's statement that all ANONYMOUS users have the >> _same_ authorization ID, not _no_ authorization ID. > > I think Sam's statement is problematic in that implies that the > mechanism is establishing or authenticating the user's identity. > The server might be associating an identity with anonymous > users, but the server certainly is not establishing > or authenticating the user's identity. I don't see why not. The user just doesn't have anything to do with any information sent in the authentication requests. Instead the user is built into the mechanism itself. Once it is established, it has the access which the server grants that user, just like with authenticated users. >> Which made me realize that anonymous auth is not a SASL term, but one >> I'm used to from LDAP, where it means the same as no auth. OTOH, FTP >> (at least on Unix) implements anonymous auth the way Sam describes: A >> specific user on the server's system, with limited access. > > But it should be clear that anonymous methods in LDAP, FTP, > and elsewhere are not authenticating the user's identity. In LDAP it does not authenticate. In FTP it does, to the server. The anonymous user has the access which the filesystem grants to a specific user on the filesystem. >>> (or is concealed). >> >> Oh dear. I wish you hadn't added that. > > RFC 2828: > $ anonymous > (I) The condition of having a name that is unknown or concealed. > >> Which identity do you mean? > > The identity of the user (or a user). > >> Authentication or authorization identity, after all? > > Both, as they both refer to identities of users. > >> And who is it concealed from? The server, or other users? > > In this case, they are concealed from (at least) the server. Uh... An authorization identity concealed to the server is not a concept I can quite wrap my head around. The server grants access based on some specific authorization identity. >>> Hallvard: I'm not sure what your question is (in your last >>> response). If your asking whether SASL itself or the >>> ANONYMOUS mechanism defines a particular identity representation >>> to refer to anonymous users (users which have no established >>> identity), I think the answer is no. If your asking whether >>> SASL or ANONYMOUS explicitly provides a facility for a user >>> to authenticate oneself and assume the authorization of an >>> anonymous user, I think the answer is no. >> >> Almost... I'm wondering if SASL even allows an authentication >> mechanism to revert the authentication and authorization IDs back >> to unauthenticated - that is, the same state as before the first >> authentication. > > SASL doesn't support "revert", it supports moving to a new > authorization state. Replace "revert" back to "unauthenticated", then. > That new authorization state could be an anonymous one (one where the > identity of the user is not established (authenticated)). I can't find any place in rfc2222bis which says so. Where? >> But perhaps it would be problematic if the did, >> since it would mess up for protocols that require authentication. > > ANONYMOUS allows protocols which previously required authentication > of the user to support processing without authentication of the > user. That is, it allows the "authenticate" command to be used > in a fashion which doesn't actually authenticate anything. -- Hallvard From owner-ietf-sasl Sat Apr 10 10:38:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AHcxXk060731; Sat, 10 Apr 2004 10:38:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AHcxx2060730; Sat, 10 Apr 2004 10:38:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AHcwvG060723 for ; Sat, 10 Apr 2004 10:38:58 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3AHd2Ms034086; Sat, 10 Apr 2004 17:39:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040410103203.04ae46b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 10 Apr 2004 10:38:45 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:58 AM 4/10/2004, Sam Hartman wrote: > Hallvard> See above. Also, Sam's statement that all ANONYMOUS > Hallvard> users have the _same_ authorization ID, not _no_ > Hallvard> authorization ID. Which made me realize that anonymous > Hallvard> auth is not a SASL term, but one I'm used to from LDAP, > Hallvard> where it means the same as no auth. OTOH, FTP (at least > Hallvard> on Unix) implements anonymous auth the way Sam > Hallvard> describes: A specific user on the server's system, with > Hallvard> limited access. > >I think my statement is still generally true. It may happen that the >authorization ID of anonymous users is also the same as the >authorization ID of users who have engaged in no authentication >exchange. But here you are talking about some authorization ID which the service merely associates with the state of being anonymous (having an unknown or concealed identity). This is quite different than saying that anonymous users have established (authenticated) THEIR identity in the service. Kurt From owner-ietf-sasl Sat Apr 10 11:09:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AI9TgW063801; Sat, 10 Apr 2004 11:09:30 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AI9Tih063800; Sat, 10 Apr 2004 11:09:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-FIFTY-THREE.MIT.EDU [18.187.6.98]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AI9TMw063794 for ; Sat, 10 Apr 2004 11:09:29 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 59F8815159C; Sat, 10 Apr 2004 14:09:29 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410103203.04ae46b8@127.0.0.1> From: Sam Hartman Date: Sat, 10 Apr 2004 14:09:29 -0400 In-Reply-To: <6.0.1.1.0.20040410103203.04ae46b8@127.0.0.1> (Kurt D. Zeilenga's message of "Sat, 10 Apr 2004 10:38:45 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> At 09:58 AM 4/10/2004, Sam Hartman wrote: Hallvard> See above. Also, Sam's statement that all ANONYMOUS Hallvard> users have the _same_ authorization ID, not _no_ Hallvard> authorization ID. Which made me realize that anonymous Hallvard> auth is not a SASL term, but one I'm used to from LDAP, Hallvard> where it means the same as no auth. OTOH, FTP (at least Hallvard> on Unix) implements anonymous auth the way Sam Hallvard> describes: A specific user on the server's system, with Hallvard> limited access. >> I think my statement is still generally true. It may happen >> that the authorization ID of anonymous users is also the same >> as the authorization ID of users who have engaged in no >> authentication exchange. Kurt> But here you are talking about some authorization ID which Kurt> the service merely associates with the state of being Kurt> anonymous (having an unknown or concealed identity). Agree.d Kurt> This Kurt> is quite different than saying that anonymous users have Kurt> established (authenticated) THEIR identity in the service. I don't see the difference. IN both cases, the identity (or non-identity) you are authorized as establishes your privileges in the system. From owner-ietf-sasl Sat Apr 10 13:04:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AK46Zf076083; Sat, 10 Apr 2004 13:04:06 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AK45GE076082; Sat, 10 Apr 2004 13:04:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AK44DP076076 for ; Sat, 10 Apr 2004 13:04:04 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3AK49Ms036300; Sat, 10 Apr 2004 20:04:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040410110652.04af8cf8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 10 Apr 2004 13:03:52 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication Cc: Sam Hartman , ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@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:33 AM 4/10/2004, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>At 07:53 AM 4/10/2004, Hallvard B Furuseth wrote: >>>Kurt D. Zeilenga writes: >>>>At 09:41 AM 4/7/2004, Sam Hartman wrote: >>>>>>>>>> "Hallvard" == Hallvard B Furuseth writes: >>>>> >>>> The anonymous mechanism doesn't provide any >>>> authentication service. (Not all SASL mechanisms provide >>>> authentication services.) >>> >>> That's not what rfc2222bis says. It describes SASL mechanisms as >>> authentication mechanisms, and describes everything about these in >>> terms of authentication. >> >> Which is a problem. rfc2222bis should be likely use more >> generic terms, like "SASL mechanism" when referring to a >> SASL mechanism. > >rfc2222 does the same thing. RFC 2222 only once used the term "authentication mechanism". This was in the security consideration section, when referring to relative strengths of various mechanisms. It failed to distinguish that some mechanisms do not provide authentication services. That should be corrected. Everywhere else in RFC 2222, RFC 2222 used generic terms. >Did it incorrectly describe existing >implementations, or were mechanisms like ANONYMOUS added later? Often one describes features of protocols based upon what purpose they generally serve even though they might not always be used for that purpose. See say "security layer" even though the feature (say data compression) may not used to provide non-security layer . The fact that we name these features as we do, it should be made clear that they do not always provide the function the names imply. This should be made clear in RFC 2222. >>> One which doesn't authenticate, from what you say. >> >> I would hope it obvious that ANONYMOUS does not authenticate anything. > >If it affects the authorization or authentication IDs, it... well, yes. >un-authenticates, I suppose. I prefer to say that the ANONYMOUS mechanism, like all mechanisms, is used to establish a new authorization state which displaces the previous authorization state. In particular, ANONYMOUS is used to establish an anonymous authorization state. That is, the purpose of ANONYMOUS is to provide access of that of a user without requiring the user to establish their identity. >If it doesn't, it seems to violate rfc2222 and rfc2222bis. I think ANONYMOUS is fairly consistent with RFC 2222 and 2222bis. I think 2222bis needs some further clarification here and there. >>> However, I think the ANONYMOUS draft does need to say explicitly how it >>> affects the authentication and authorization IDs. >> >> How any mechanism affects authentication and authorization IDs >> outside of the mechanism is beyond the scope of that mechanism. > >Beyond the scope of any mechanism, I think. > >Correction: It needs to say which authentication and authorization IDs >it _requests_. Or provides, or whatever is the correct term. Hopefully >these IDs will be treated just like IDs from other SASL mechanisms. >Or like no ID (unauthenticated), if that's what the mechanism requests. ANONYMOUS doesn't request nor provide an authentication ID nor an authorization ID. Note that there could be other mechanisms would also do not provide such IDs to the server. Consider a mechanism which only authenticated the server to the client. Anyways, I think it sufficient for the mechanism to say what it provides (no IDs in the case of ANONYMOUS). How that's used in application protocol (or implementations thereof) is simply beyond the scope of the mechanism specification. >> It should be obvious that this mechanism does not itself >> establish an authentication identity nor transfer an authorization >> identity. However, if more clarity is needed, I would suggest >> replacing the paragraph: >> This mechanism does not provide a security layer. >> with: >> This mechanism does not establish the identity of the >> client (or user) nor the server (or service); does not >> support transfer of an authorization identity; nor >> provide a security layer. > >I think either 'It requests anonymous authentication and authorization >identities. I assume It == user here. I'm describing what the mechanism establishes and not (in this paragraph) what the user may or may not request using this mechanism. >How to treat the anonymous ID is up to the protocol or >implementation.', or 'It does not affect the authentication and >authorization identities'. The latter is especially dangerous because confusing between whether we're talking about the identity established by the user through authentication, and some identity value which represents the user has not established THEIR identity through authentication. >>> Also, I now wonder how clients typically implement ANONYMOUS. If they >>> support several SASL mechanisms, do clients expect the identity to send >>> with ANONYMOUS in the same command line option or whatever which they >>> use for the authentication IDs for other SASL mechanisms, or do they use >>> some other field? >> >> I suggest you look at some existing implementations. > >I don't know where to find any... Cyrus SASL? >> But >> I would hope the user would not be asked or expected to >> provide their credentials (or portions of their credentials) >> when using this mechanism. > >If you mean e.g. a password, I agree. I mean credentials. Credentials may include many things... and generally (but not necessarily) includes a representation of the identity they are used to establish. For instance, in PLAIN, the credentials include both a representation of the user's identity and a password. The user has to know both to gain access as that user. >However, I was thinking of >clients that authenticate to the server Who are they authenticating? Themselves or whatever entity is using the client? SASL general function is to authenticate the client (or entity which is using a client) to the server. It's not to authenticate the entity using the client to the client. This is not to say that clients cannot do that, but the security considerations for using SASL in this fashion are broad and wide. >and then grant access to >something on the client side depending on whether or not authentication >succeeds. Such a client would need to treat ANONYMOUS as not establishing the user's entity. Here, at least, the client can just disallow the mechanism. A client which uses PLAIN, CRAM-MD5, etc., for such has it far worse. They need to know which user names have widely known passwords or user names are granted access regardless of what password is provided. How many PLAIN deployments out there accept any password for "anonymous"? >Such a client must not treat the ID sent with ANONYMOUS as an >authentication ID. Whether the trace information provided by the client has any semantical value to the client is beyond the scope of the mechanism. The mechanism is quite clear that the email address, if provided, as no semantical value to the mechanism and should only be used by the server for trace purposes. >Or it could refuse the user to specify the ANONYMOUS >mechanism, of course. If a client is going to use mechanisms to authorize users to access services AT the client, then it needs to understand not only the services provided by the mechanism, but protocol/implementation/deployment details of the server it using in support of user authentication to the client. >>>> I also find it odd the implication (in Hallvard's comments) that an >>>> anonymous user has an established identity. I take the view that an >>>> anonymous user is one whose's identity has not been established >>> >>> See above. Also, Sam's statement that all ANONYMOUS users have the >>> _same_ authorization ID, not _no_ authorization ID. >> >> I think Sam's statement is problematic in that implies that the >> mechanism is establishing or authenticating the user's identity. >> The server might be associating an identity with anonymous >> users, but the server certainly is not establishing >> or authenticating the user's identity. > >I don't see why not. The user just doesn't have anything to do with any >information sent in the authentication requests. Instead the user is >built into the mechanism itself. Once it is established, it has the >access which the server grants that user, just like with authenticated >users. The distinction is wether or not the mechanism is authenticating the user's identity or whether the server-side implementation of the mechanism is merely associating some identity representation that indicates that the user's identity has not been established by the mechanism. That latter is an implementation detail. >>> Which made me realize that anonymous auth is not a SASL term, but one >>> I'm used to from LDAP, where it means the same as no auth. OTOH, FTP >>> (at least on Unix) implements anonymous auth the way Sam describes: A >>> specific user on the server's system, with limited access. >> >> But it should be clear that anonymous methods in LDAP, FTP, >> and elsewhere are not authenticating the user's identity. > >In LDAP it does not authenticate. In FTP it does, to the server. The >anonymous user has the access which the filesystem grants to a specific >user on the filesystem. The problem with your statement, in my opinion, is the implication that the user's identity seeking anonymous access has THEIR identity authenticated. No, the user seeking anonymous access is asserting a well-known account name which grants access to anyone and everyone regardless of what password is provided. So, while one is going through a login process, it is an anonymous login process. That is, the user is not required to provide THEIR credentials for authentication. They are granted access without authentication of who THEY are. It should be clear in ANONYMOUS that there is no well-known identity representation transferred to obtain anonymous access nor is any particular identity representation implies to have been transferred to the server by use of ANONYMOUS. >>>> (or is concealed). >>> >>> Oh dear. I wish you hadn't added that. >> >> RFC 2828: >> $ anonymous >> (I) The condition of having a name that is unknown or concealed. >> >>> Which identity do you mean? >> >> The identity of the user (or a user). >> >>> Authentication or authorization identity, after all? >> >> Both, as they both refer to identities of users. >> >>> And who is it concealed from? The server, or other users? >> >> In this case, they are concealed from (at least) the server. > >Uh... An authorization identity concealed to the server is not >a concept I can quite wrap my head around. The server grants >access based on some specific authorization identity. Or lack thereof. But more to the point is that the authorization identity it uses is something it constructs (possible directly from information provided in the exchange). A user can be said to be anonymous to the server if the identity of THAT user (a particular user) is not known to the server. That is, the identity of the user has been concealed by the user, the client, and the choice of mechanism. Hence, where a server might associate some special authorization identity representation to all users who have not established their identity as implying that the special identity representation used by the server is authenticated or identifies the particular user. >>>> Hallvard: I'm not sure what your question is (in your last >>>> response). If your asking whether SASL itself or the >>>> ANONYMOUS mechanism defines a particular identity representation >>>> to refer to anonymous users (users which have no established >>>> identity), I think the answer is no. If your asking whether >>>> SASL or ANONYMOUS explicitly provides a facility for a user >>>> to authenticate oneself and assume the authorization of an >>>> anonymous user, I think the answer is no. >>> >>> Almost... I'm wondering if SASL even allows an authentication >>> mechanism to revert the authentication and authorization IDs back >>> to unauthenticated - that is, the same state as before the first >>> authentication. >> >> SASL doesn't support "revert", it supports moving to a new >> authorization state. > >Replace "revert" back to "unauthenticated", then. That would make even less sense: unauthenticate the authentication ID? >> That new authorization state could be an anonymous one (one where the >> identity of the user is not established (authenticated)). > >I can't find any place in rfc2222bis which says so. Where? As I said before, RFC 2222bis needs work here. A number of the clarifications added to RFC 2222bis are causing confusion. Those clarifications need refinement. From owner-ietf-sasl Sat Apr 10 13:25:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AKPY2e077843; Sat, 10 Apr 2004 13:25:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AKPYFZ077842; Sat, 10 Apr 2004 13:25:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AKPXSG077836 for ; Sat, 10 Apr 2004 13:25:34 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3AKPcMs036626; Sat, 10 Apr 2004 20:25:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040410130528.04b19dd8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 10 Apr 2004 13:25:22 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410103203.04ae46b8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:09 AM 4/10/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> At 09:58 AM 4/10/2004, Sam Hartman wrote: > Hallvard> See above. Also, Sam's statement that all ANONYMOUS > Hallvard> users have the _same_ authorization ID, not _no_ > Hallvard> authorization ID. Which made me realize that anonymous > Hallvard> auth is not a SASL term, but one I'm used to from LDAP, > Hallvard> where it means the same as no auth. OTOH, FTP (at least > Hallvard> on Unix) implements anonymous auth the way Sam > Hallvard> describes: A specific user on the server's system, with > Hallvard> limited access. > >> I think my statement is still generally true. It may happen > >> that the authorization ID of anonymous users is also the same > >> as the authorization ID of users who have engaged in no > >> authentication exchange. > > Kurt> But here you are talking about some authorization ID which > Kurt> the service merely associates with the state of being > Kurt> anonymous (having an unknown or concealed identity). > >Agree.d > > Kurt> This > Kurt> is quite different than saying that anonymous users have > Kurt> established (authenticated) THEIR identity in the service. > >I don't see the difference. IN both cases, the identity (or >non-identity) you are authorized as establishes your privileges in the >system. The difference is that, when using ANONYMOUS, users don't establish THEIR identity, they establish some factor in the server which allows them access without requiring that they establish THEIR identity. Sure, a system can associate some identity representation to all users which have not established THEIR identity, but that imply the user has established THEIR identity. And, I would hope, we can agree on whether or not the system does associate some identity representation to all users which not established THEIR identities or not, or what that identity representation might be, is completely beyond the scope of this mechanism. Just as what authorization identity representation the system might associate with an user who DOES establish their identity is beyond the scope of the mechanism. From owner-ietf-sasl Sat Apr 10 13:58:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AKwIvq081233; Sat, 10 Apr 2004 13:58:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AKwI98081232; Sat, 10 Apr 2004 13:58:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-FIFTY-THREE.MIT.EDU [18.187.6.98]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AKwGhv081226 for ; Sat, 10 Apr 2004 13:58:16 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 7218415159C; Sat, 10 Apr 2004 16:58:21 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410103203.04ae46b8@127.0.0.1> <6.0.1.1.0.20040410130528.04b19dd8@127.0.0.1> From: Sam Hartman Date: Sat, 10 Apr 2004 16:58:21 -0400 In-Reply-To: <6.0.1.1.0.20040410130528.04b19dd8@127.0.0.1> (Kurt D. Zeilenga's message of "Sat, 10 Apr 2004 13:25:22 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> This is quite different than saying that anonymous users Kurt> have established (authenticated) THEIR identity in the Kurt> service. >> I don't see the difference. IN both cases, the identity (or >> non-identity) you are authorized as establishes your privileges >> in the system. Kurt> The difference is that, when using ANONYMOUS, users don't Kurt> establish THEIR identity, they establish some factor in the Kurt> server which allows them access without requiring that they Kurt> establish THEIR identity. That sort of depends on your model for identity. It seems completely reasonable to say something along the following lines. Anonymous establishes the anonymous identity with no confidence in that identity. IP address-based authentication establishes an identity based on the IP address with low confidence in that identity. AUthentication by assertion establishes the asserted identity with low confidence in that assertion. External authentication with a client TLS certificate establishes the SubjectName of the certificate as the identity with reasonably high confidence in that identity. Now in this working group we don't really care about the properties of the identity established by anonymous authentication. For example, we don't care if the identities resulting from two different anonymous authentications compare to be equal or are guaranteed to be distinct. You probably want one of the two to be true and for most purposes you don't care which. Again, I think we are arguing about isomorphic models. Conceptually,believe there is an identity and some factor indicating whether the identity has been established. I believe that one class of identity is the unestablished identity. So why am I arguing over isomorphisms? Unfortunately, the particular conceptual model we use seems to appear at least in part in the text of the base specification. I believe that treating everything as authentication will make that base specification easier to understand at the cost of hiding conceptual complexity in anonymous. I may be wrong; this may confuse people to much and be important to change. I'm also arguing to show that this is not an editorial correction to the base specification. You're proposing changing how we think about SASL or at least expanding an area of thought about SASL where our previous thinking was vague. Making that change is a reasonable thing for the working group to do, but it does need to meet a slightly higher bar than an editorialclarification. Kurt> Sure, a system can associate some Kurt> identity representation to all users which have not Kurt> established THEIR identity, but that imply the user has Kurt> established THEIR identity. Kurt> And, I would hope, we can agree on whether or not the system Kurt> does associate some identity representation to all users Kurt> which not established THEIR identities or not, or what that Kurt> identity representation might be, is completely beyond the Kurt> scope of this mechanism. Just as what authorization Kurt> identity representation the system might associate with an Kurt> user who DOES establish their identity is beyond the scope Kurt> of the mechanism. Agreed. From owner-ietf-sasl Sat Apr 10 13:47:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AKlKAh080090; Sat, 10 Apr 2004 13:47:20 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AKlKSi080089; Sat, 10 Apr 2004 13:47:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AKlKEk080083 for ; Sat, 10 Apr 2004 13:47:20 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3AKlOMs036861; Sat, 10 Apr 2004 20:47:24 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040410134518.04ae6468@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 10 Apr 2004 13:47:08 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication [corrected] Cc: Hallvard B Furuseth , ietf-sasl@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I need to slow down... At 11:09 AM 4/10/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> At 09:58 AM 4/10/2004, Sam Hartman wrote: > Hallvard> See above. Also, Sam's statement that all ANONYMOUS > Hallvard> users have the _same_ authorization ID, not _no_ > Hallvard> authorization ID. Which made me realize that anonymous > Hallvard> auth is not a SASL term, but one I'm used to from LDAP, > Hallvard> where it means the same as no auth. OTOH, FTP (at least > Hallvard> on Unix) implements anonymous auth the way Sam > Hallvard> describes: A specific user on the server's system, with > Hallvard> limited access. > >> I think my statement is still generally true. It may happen > >> that the authorization ID of anonymous users is also the same > >> as the authorization ID of users who have engaged in no > >> authentication exchange. > > Kurt> But here you are talking about some authorization ID which > Kurt> the service merely associates with the state of being > Kurt> anonymous (having an unknown or concealed identity). > >Agree.d > > Kurt> This > Kurt> is quite different than saying that anonymous users have > Kurt> established (authenticated) THEIR identity in the service. > >I don't see the difference. IN both cases, the identity (or >non-identity) you are authorized as establishes your privileges in the >system. The difference is that, when using ANONYMOUS, users don't establish THEIR identity, they establish some factor in the server which allows them access without requiring that they establish THEIR identity. Sure, a system can associate some identity representation to all users which have not established THEIR identity, but that DOES NOT imply the user has established THEIR identity. And, I would hope, we can agree on whether or not the system does associate some identity representation to all users which not established THEIR identities or not, or what that identity representation might be, is completely beyond the scope of this mechanism. Just as what authorization identity representation the system might associate with an user who DOES establish their identity is beyond the scope of the mechanism. From owner-ietf-sasl Sat Apr 10 17:49:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3B0nE4q000514; Sat, 10 Apr 2004 17:49:14 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3B0nERJ000513; Sat, 10 Apr 2004 17:49:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3B0nELb000505 for ; Sat, 10 Apr 2004 17:49:14 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3B0nJMs040892; Sun, 11 Apr 2004 00:49:19 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040410145813.0526eb00@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 10 Apr 2004 17:49:02 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410103203.04ae46b8@127.0.0.1> <6.0.1.1.0.20040410130528.04b19dd8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 01:58 PM 4/10/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> This is quite different than saying that anonymous users > Kurt> have established (authenticated) THEIR identity in the > Kurt> service. > >> I don't see the difference. IN both cases, the identity (or > >> non-identity) you are authorized as establishes your privileges > >> in the system. > > Kurt> The difference is that, when using ANONYMOUS, users don't > Kurt> establish THEIR identity, they establish some factor in the > Kurt> server which allows them access without requiring that they > Kurt> establish THEIR identity. >That sort of depends on your model for identity. I think it depends more on who is establishing what, and by what means. When ANONYMOUS is being used, the USER is not required to establish THEIR identity. Whether or not the server-side mechanism implementation represents, or how it represents, to the server-side protocol implementation that the USER has requested access be granted on an anonymous-basis (e.g, with requiring the USER to establish THEIR identity), as well as how that server-side protocol implementation might then use this information in authorization decisions is a separate (and separable) issue. >It seems completely reasonable to say something along the following >lines. Anonymous establishes the anonymous identity with no >confidence in that identity. IP address-based authentication >establishes an identity based on the IP address with low confidence in >that identity. AUthentication by assertion establishes the asserted >identity with low confidence in that assertion. External >authentication with a client TLS certificate establishes the >SubjectName of the certificate as the identity with reasonably high >confidence in that identity. In the three non-anonymous examples you provide, each requires the user to disclose its identity. In the anonymous case, the user is not required to disclose information its identity (though the user might be identifiable otherwise). So, I think, your analogy is a bit flawed. But, what concerns me is implication that the ANONYMOUS mechanism establishes through the exchange an identity representation that refers users who have not established their entity. I find that implication misleading and confusing. If such a representation is to be established, it's being established by, for, and within server implementation. That is, such is being manufactured outside of the mechanism exchange as defined by this specification. >Now in this working group we don't really care about the properties of >the identity established by anonymous authentication. For example, we >don't care if the identities resulting from two different anonymous >authentications compare to be equal or are guaranteed to be distinct. I agree. >Again, I think we are arguing about isomorphic models. >Conceptually,believe there is an identity and some factor indicating >whether the identity has been established. I believe that one class >of identity is the unestablished identity. > >So why am I arguing over isomorphisms? I think we're arguing over whether "to authenticate" means "to verify" or whether it means "to login (with our without verification)". SASL mechanisms are login mechanisms: some provide authenticated login capabilities, some provide anonymous login capabilities. >Unfortunately, the particular >conceptual model we use seems to appear at least in part in the text >of the base specification. I think the base specification has problems in three areas (that impact this discussion): 1) The base specification does not use terms consistently, 2) The base specification doesn't always define the terms it uses, and 3) The base specification is not clear that as to the range of function that a SASL mechanism can provide. >I believe that treating everything as >authentication will make that base specification easier to understand >at the cost of hiding conceptual complexity in anonymous. To a certain degree I agree that some of the conceptual complexity can be hidden in ANONYMOUS, excepting the base specification needs to be clear that not everything fits the easier to understand model which the base specification puts forth. Anyways, in regards to the ANONYMOUS specification, I'm going to offer a slightly revised intro text for the WG to consider here shortly. However, I think the base specification needs work to be more easily understood. For instance, 2222bis uses of the terms: SASL authentication mechanism, SASL mechanism, authentication mechanism, and mechanism generally in an interchangeable fashion. However, in some uses in the document where it obvious that they are not interchangeable. This confuses all the uses which the author used them interchangeable, leaving a mess for the reader to decipher. I think it would be far better if we would consistently use the term "SASL mechanism" (and "mechanism" only where it is clear we're referring to a SASL mechanism) as RFC 2222 generally did. And I think we should be more clear as to what functions SASL mechanisms generally provide (and how some may offer vastly different functions than other mechanisms). >I may be wrong; this may confuse people to much and be important to change. At the moment, some readers of 2222bis are going to be confused as some of the terminology is new and different than what was used in RFC 2222, BUT the largest problem is that much of the terminology (new and old) is not well-defined and/or not used consistently. >I'm also arguing to show that this is not an editorial correction to >the base specification. You're proposing changing how we think about >SASL or at least expanding an area of thought about SASL where our >previous thinking was vague. I don't think I am arguing that we change how we think about SASL. I am mostly arguing that we clean up our terminology. And I am objecting to use of language which is not consistent with our terminology. Of course, "what is our terminology" is a bit of an open question given that 2222bis does well-define our terminology. >Making that change is a reasonable thing >for the working group to do, but it does need to meet a slightly >higher bar than an editorialclarification. Inconsistent use of poorly-defined terminology is, I think, not just an "editorial clarification" concern, it's a general technical quality concern. Kurt From owner-ietf-sasl Sun Apr 11 11:33:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BIXskd081887; Sun, 11 Apr 2004 11:33:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3BIXsM8081886; Sun, 11 Apr 2004 11:33:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BIXqjQ081860 for ; Sun, 11 Apr 2004 11:33:53 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1BCjmA-0001tf-SQ; Sun, 11 Apr 2004 20:33:50 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.30) id 1BCjm6-0007L6-LP; Sun, 11 Apr 2004 20:33:46 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BCjm5-0006MU-00; Sun, 11 Apr 2004 20:33:45 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Sam Hartman , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication In-Reply-To: <6.0.1.1.0.20040410110652.04af8cf8@127.0.0.1> References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> <6.0.1.1.0.20040410110652.04af8cf8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sun, 11 Apr 2004 20:33:45 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >At 10:33 AM 4/10/2004, Hallvard B Furuseth wrote: >>Kurt D. Zeilenga writes: >>>At 07:53 AM 4/10/2004, Hallvard B Furuseth wrote: >>>>Kurt D. Zeilenga writes: >>>>> The anonymous mechanism doesn't provide any >>>>> authentication service. (Not all SASL mechanisms provide >>>>> authentication services.) >>>> >>>> That's not what rfc2222bis says. It describes SASL mechanisms as >>>> authentication mechanisms, and describes everything about these in >>>> terms of authentication. >>> >>> Which is a problem. rfc2222bis should be likely use more >>> generic terms, like "SASL mechanism" when referring to a >>> SASL mechanism. >> >> rfc2222 does the same thing. > > RFC 2222 only once used the term "authentication mechanism". > This was in the security consideration section, Sorry, I should have said I looked for 'authentication' and 'authorization' in general. In particular the term 'authentication protocol exchange' is recurring. E.g.: 3. Introduction and Overview The Simple Authentication and Security Layer (SASL) is a method for adding authentication support to connection-based protocols. (...) If a server supports the requested mechanism, it initiates an authentication protocol exchange. (...) During the authentication protocol exchange, the mechanism performs authentication, transmits an authorization identity (...) 5.3. Multiple authentications 4. Profiling requirements 5. A specification of how the authorization identity passed from the client to the server is to be interpreted. [ANONYMOUS] does not fulfill that requirement. >> Did it incorrectly describe existing >> implementations, or were mechanisms like ANONYMOUS added later? > > Often one describes features of protocols based upon what > purpose they generally serve even though they might not > always be used for that purpose. See say "security layer" > even though the feature (say data compression) may not used > to provide non-security layer . > > The fact that we name these features as we do, it should be > made clear that they do not always provide the function the > names imply. This should be made clear in RFC 2222. True. (I approached this whole thing from the point of view of a user of a SASL library, who knows SASL but may not be aware that there are mechanisms that do not provide what the SASL spec might make one assume it provides.) >> Correction: It needs to say which authentication and authorization IDs >> it _requests_. Or provides, or whatever is the correct term. Hopefully >> these IDs will be treated just like IDs from other SASL mechanisms. >> Or like no ID (unauthenticated), if that's what the mechanism requests. > > ANONYMOUS doesn't request nor provide an authentication ID nor an > authorization ID. There has to be _some_ way to say that ANONYMOUS changes the authentication ID, or requests a change of it, or however you wish to say that, and what that new ID is, or that the new ID is absent, or however you wish to say that. Could you please provide a wording for that which you will accept, so we can at least talk about how it relates to the authentication ID? Maybe just some wording to satisfy the SASL 'Profiling requirements' requirement above. I'll hold off replying to part of your message (if a reply to the rest still seems relevant) until then. > Note that there could be other mechanisms would also do not > provide such IDs to the server. See the section from '4. Profiling requirements' quoted above. > Consider a mechanism which > only authenticated the server to the client. Hmm - I suppose the mechanism could specify that the authentication ID is the one which was already in use. > Anyways, I think it sufficient for the mechanism to say what it > provides (no IDs in the case of ANONYMOUS). How that's used > in application protocol (or implementations thereof) is simply > beyond the scope of the mechanism specification. Yes. >>> It should be obvious that this mechanism does not itself >>> establish an authentication identity nor transfer an authorization >>> identity. However, if more clarity is needed, I would suggest >>> replacing the paragraph: >>> This mechanism does not provide a security layer. >>> with: >>> This mechanism does not establish the identity of the >>> client (or user) nor the server (or service); does not >>> support transfer of an authorization identity; nor >>> provide a security layer. >> >> I think either 'It requests anonymous authentication and authorization >> identities. > > I assume It == user here. I meant it = mechanism. Though it's on behalf of the user, if that's what you mean. > I'm describing what the mechanism > establishes and not (in this paragraph) what the user may or > may not request using this mechanism. But 'establishes' is wrong - as you said, how any mechanism affects authentication and authorization IDs outside of the mechanism is beyond the scope of that mechanism. >> How to treat the anonymous ID is up to the protocol or >> implementation.', or 'It does not affect the authentication and >> authorization identities'. > > The latter is especially dangerous Well, I hoped that was not what it does. Your recent messages in this thread just made me wonder if it did. >>>> Also, I now wonder how clients typically implement ANONYMOUS. If they >>>> support several SASL mechanisms, do clients expect the identity to send >>>> with ANONYMOUS in the same command line option or whatever which they >>>> use for the authentication IDs for other SASL mechanisms, or do they use >>>> some other field? >>> >>> I suggest you look at some existing implementations. >> >> I don't know where to find any... > > Cyrus SASL? Yes. But a client and a server which uses the mechanism? Anyway, I kind of hoped someone who already use SASL could tell me, so I won't have to compile and install stuff just to find out. The only example I know of is openldap ldapsearch. It does not treat auth(c/z) ID as trace ID. >>> But >>> I would hope the user would not be asked or expected to >>> provide their credentials (or portions of their credentials) >>> when using this mechanism. >> >> If you mean e.g. a password, I agree. > > I mean credentials. Credentials may include many things... > and generally (but not necessarily) includes a representation of > the identity they are used to establish. For instance, in > PLAIN, the credentials include both a representation of > the user's identity and a password. The user has to know > both to gain access as that user. OK. >> However, I was thinking of >> clients that authenticate to the server > > Who are they authenticating? Themselves or whatever entity is > using the client? SASL general function is to authenticate > the client (or entity which is using a client) to the server. Sure. > It's not to authenticate the entity using the client to the > client. > > This is not to say that clients cannot do that, but the > security considerations for using SASL in this fashion are > broad and wide. Perhaps they should be discussed in rfc2222bis? >> and then grant access to >> something on the client side depending on whether or not authentication >> succeeds. > > Such a client would need to treat ANONYMOUS as not establishing > the user's entity. Here, at least, the client can just disallow > the mechanism. A client which uses PLAIN, CRAM-MD5, etc., for > such has it far worse. They need to know which user names > have widely known passwords or user names are granted access > regardless of what password is provided. How many PLAIN > deployments out there accept any password for "anonymous"? Do you mean such things come with the default SASL setup with some implementations? That sounds scary enough that it might be an idea to warn about it in rfc2222bis. Otherwise I don't see the problem. The client will authenticate against a server which it knows is set up to authenticate the possible users of that clients. Other user names will not be recognized. Except ANONYMOUS "user names", if the client treats the trace information sent with ANONYMOUS the same way it treats user names for other mechanisms. Anyway, I simply wondered if clients do that. I hope not. >> Or it could refuse the user to specify the ANONYMOUS >> mechanism, of course. > > If a client is going to use mechanisms to authorize users > to access services AT the client, then it needs to understand > not only the services provided by the mechanism, but > protocol/implementation/deployment details of the server > it using in support of user authentication to the client. OK. >>> But it should be clear that anonymous methods in LDAP, FTP, >>> and elsewhere are not authenticating the user's identity. >> >> In LDAP it does not authenticate. In FTP it does, to the server. The >> anonymous user has the access which the filesystem grants to a specific >> user on the filesystem. > > The problem with your statement, in my opinion, is the > implication that the user's identity seeking anonymous > access has THEIR identity authenticated. (...) I don't think so. Users of shared accounts don't authenticate as THEIR identities either. My nearest public library has the public account's username and password taped to the public computers, so people can reboot the beasts without running to a librarian for help. That's not the user's identity either. All that any SASL mechanism authenticates is that the client provided sufficient credentials to authenticate in the manner it did. Which is none at all, in the ANONYMOUS case. The administrator who allowed that authentication is the one who knows what it means that someone authenticated that way, and what access to grant. -- Hallvard From owner-ietf-sasl Sun Apr 11 11:41:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BIf5H1083134; Sun, 11 Apr 2004 11:41:05 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3BIf55C083133; Sun, 11 Apr 2004 11:41:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BIf4nt083118 for ; Sun, 11 Apr 2004 11:41:05 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1BCjt9-00035M-GK; Sun, 11 Apr 2004 20:41:03 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.30) id 1BCjt3-00085A-11; Sun, 11 Apr 2004 20:40:57 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BCjt2-0006Mp-00; Sun, 11 Apr 2004 20:40:56 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Sam Hartman , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> <6.0.1.1.0.20040410110652.04af8cf8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sun, 11 Apr 2004 20:40:56 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Grumble. Read through a message two times before sending, then discover a mistake just after sending:-( I wrote: > 4. Profiling requirements > 5. A specification of how the authorization identity passed from the > client to the server is to be interpreted. > > [ANONYMOUS] does not fulfill that requirement. I meant, [ANONYMOUS] as currently described, or as you describe it, does not provide such an authorization identity for the protocol to interpret. Even if it is not 'passed from the client', the protocol spec needs to get an authorization identity from the SASL mechanism in order to fulfill this requirement. -- Hallvard From owner-ietf-sasl Sun Apr 11 11:54:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BIsf8B084826; Sun, 11 Apr 2004 11:54:41 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3BIsfR3084824; Sun, 11 Apr 2004 11:54:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BIseVW084811 for ; Sun, 11 Apr 2004 11:54:40 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1BCk6L-0005QB-64 for ietf-sasl@imc.org; Sun, 11 Apr 2004 20:54:41 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.30) id 1BCk6I-0000sg-6j; Sun, 11 Apr 2004 20:54:38 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BCk6H-0006PO-00; Sun, 11 Apr 2004 20:54:37 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis: authentication identity Date: Sun, 11 Apr 2004 20:54:37 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: rfc2222bis has added the concept of an authentication identity since rfc2222. Is this identity only a parameter to the SASL authentication process, and can be discarded after SASL authentication is complete? Or is it also part of the connecton's authorization state after SASL authentication? If so, what for? Could you clarify that in the draft? -- Hallvard From owner-ietf-sasl Sun Apr 11 14:00:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BL0QmD003224; Sun, 11 Apr 2004 14:00:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3BL0QOO003223; Sun, 11 Apr 2004 14:00:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BL0P9d003217 for ; Sun, 11 Apr 2004 14:00:25 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3BL0UMs055396; Sun, 11 Apr 2004 21:00:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040411121900.04ad5490@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sun, 11 Apr 2004 14:00:12 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication Cc: Sam Hartman , ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> <6.0.1.1.0.20040410110652.04af8cf8@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: As I noted in my response, we use often use the terms based on "to authenticate" to mean "to login" instead of "to verify". I think the "A"authentication in SASL is commonly used in the "to login" fashion. rfc2222bis needs to be more clear here, as it is dangerous to say things are "authenticated" when they are not "verified". And, I think, we should avoid using terms such as "authentication mechanism" when there are reasonable alternatives (such as "SASL mechanism"). At 11:33 AM 4/11/2004, Hallvard B Furuseth wrote: >(I approached this whole thing from the point of view of a user >of a SASL library, who knows SASL but may not be aware that there are >mechanisms that do not provide what the SASL spec might make one assume >it provides.) The SASL specification should be more clear that not all mechanisms verify (or even establish) the user's identity, not all mechanisms pass authorization identity information, not all mechanism support security layers, etc.. That is, the range of function that mechanisms offer can vary widely. And, I think, it very important that to be clear that SASL does not abstract away the differences between mechanisms. Something in the client/server protocol implementation needs to deal with them. Maybe the implementation uses a SASL library that abstracts away some of these differences, but it should be clear something at both the client and the server has to deal with the differences. SASL framework doesn't hide mechanism particulars from protocols. >>> Correction: It needs to say which authentication and authorization IDs >>> it _requests_. Or provides, or whatever is the correct term. Hopefully >>> these IDs will be treated just like IDs from other SASL mechanisms. >>> Or like no ID (unauthenticated), if that's what the mechanism requests. >> >> ANONYMOUS doesn't request nor provide an authentication ID nor an >> authorization ID. > >There has to be _some_ way to say that ANONYMOUS changes the >authentication ID, or requests a change of it, or however you wish to >say that, and what that new ID is, or that the new ID is absent, or >however you wish to say that. By use of the ANONYMOUS mechanism, the client communicates to the server that the user wishes to access the services/resources provided by server on an anonymous basis (e.g., without disclosing its identity to the server). If the server is willing and able, it responds accordingly to the request and takes appropriate actions within its authorization system to grant that access. Note here the separation between what information is communicated by the mechanism and what the server implementation does with that information. Details of how identity information (including lack of knowing the user's identity) is represented by the server are outside the scope of the mechanism specification. >Could you please provide a wording for >that which you will accept, so we can at least talk about how it relates >to the authentication ID? In respect to the mechanism, no authentication ID is communicated. How a server implementation represents that no authentication ID was communicated by the mechanism is its business. >Maybe just some wording to satisfy the SASL >'Profiling requirements' requirement above. Above you called this profiling requirement: A specification of how the authorization identity passed from the client to the server is to be interpreted. This requirement means that protocol (not mechanism) specifications are to define the form used to representation the proxy authorization identity. It should not be viewed as requiring all mechanisms to actually pass a proxy authorization identity information from client-to-server. >> Anyways, I think it sufficient for the mechanism to say what it >> provides (no IDs in the case of ANONYMOUS). How that's used >> in application protocol (or implementations thereof) is simply >> beyond the scope of the mechanism specification. > >Yes. Noted. >>>> It should be obvious that this mechanism does not itself >>>> establish an authentication identity nor transfer an authorization >>>> identity. However, if more clarity is needed, I would suggest >>>> replacing the paragraph: >>>> This mechanism does not provide a security layer. >>>> with: >>>> This mechanism does not establish the identity of the >>>> client (or user) nor the server (or service); does not >>>> support transfer of an authorization identity; nor >>>> provide a security layer. >>> >>> I think either 'It requests anonymous authentication and authorization >>> identities. >> >> I assume It == user here. > >I meant it = mechanism. Though it's on behalf of the user, if that's >what you mean. > >> I'm describing what the mechanism >> establishes and not (in this paragraph) what the user may or >> may not request using this mechanism. > >But 'establishes' is wrong - as you said, how any mechanism affects >authentication and authorization IDs outside of the mechanism is beyond >the scope of that mechanism. I think you are not seeing the separation between what information a mechanism may or may not provide to the client/server, and how that information might be used by the client/server. In the above text, I was referring to what information the mechanism provides to the client/server as opposed to affects which are outside the mechanism. >> Cyrus SASL? > >Yes. But a client and a server which uses the mechanism? I believe you can configure OpenLDAP to make use of the mechanism. Likely Cyrus SASL's own sample client/server may use this mechanism. >Anyway, I kind of hoped someone who already use SASL could tell me, >so I won't have to compile and install stuff just to find out. It's no different than supporting any other mechanism. You need to understand what information the mechanism provide, its semantics, and then map that information into your authorization system. SASL itself doesn't abstract away mechanism differences (but your SASL library might). >The only example I know of is openldap ldapsearch. It does not >treat auth(c/z) ID as trace ID. GOOD. >> It's not to authenticate the entity using the client to the >> client. >> >> This is not to say that clients cannot do that, but the >> security considerations for using SASL in this fashion are >> broad and wide. > >Perhaps they should be discussed in rfc2222bis? Like, in my best Elmer Fudd voice, "be very, very careful" :-) >>> and then grant access to >>> something on the client side depending on whether or not authentication >>> succeeds. >> >> Such a client would need to treat ANONYMOUS as not establishing >> the user's entity. Here, at least, the client can just disallow >> the mechanism. A client which uses PLAIN, CRAM-MD5, etc., for >> such has it far worse. They need to know which user names >> have widely known passwords or user names are granted access >> regardless of what password is provided. How many PLAIN >> deployments out there accept any password for "anonymous"? > >Do you mean such things come with the default SASL setup with some >implementations? That sounds scary enough that it might be an idea to >warn about it in rfc2222bis. I think we need a brief warning. SASL purpose is to "login" the client to the server. It's not designed "login" the user to the client. What the server might find acceptable, may not be acceptable to the client. >Client's using SASL for the purposes of granting access to services/resources >at the client should be "very, very careful" not to make invalid assumptions >about the success (or failure) of a SASL mechanism exchange. >All that any SASL mechanism authenticates is that the client provided >sufficient credentials to authenticate in the manner it did. Which is >none at all, in the ANONYMOUS case. The administrator who allowed >that authentication is the one who knows what it means that someone >authenticated that way, and what access to grant. Noting that you are using the "to authenticate" (and variants) to mean "to login", I would have to agree with this statement. In particular, I agree that client does not provide any credentials when using the ANONYMOUS mechanism. This has been one of my points through this discussion. Kurt From owner-ietf-sasl Sun Apr 11 19:49:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3C2nQ6Y045832; Sun, 11 Apr 2004 19:49:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3C2nQns045831; Sun, 11 Apr 2004 19:49:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3C2nPAh045822 for ; Sun, 11 Apr 2004 19:49:25 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3C2nWMs060390 for ; Mon, 12 Apr 2004 02:49:32 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040411194237.0491d150@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sun, 11 Apr 2004 19:49:14 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: clarification as to the purpose of ANONYMOUS mechanism 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: In response to recent discussions on this list, I propose to insert the following paragraph between the existing first and second paragraphs of Section 1 of draft-ietf-sasl-anon-xx.txt: Unlike many other SASL mechanisms whose purpose is to authenticate and identify the user to a server, the purpose of this SASL mechanism is to allow the user to gain access to services or resources without requiring the user to establish or otherwise disclose their identity to the server. That is, this mechanism provides an anonymous login method. Comments? Kurt From owner-ietf-sasl Mon Apr 12 09:03:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CG3vCa014178; Mon, 12 Apr 2004 09:03:57 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CG3vhG014177; Mon, 12 Apr 2004 09:03:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-FIFTY-THREE.MIT.EDU [18.187.6.98]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CG3uuF014170 for ; Mon, 12 Apr 2004 09:03:56 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 6CDF715159C; Mon, 12 Apr 2004 12:03:59 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> <6.0.1.1.0.20040410110652.04af8cf8@127.0.0.1> <6.0.1.1.0.20040411121900.04ad5490@127.0.0.1> From: Sam Hartman Date: Mon, 12 Apr 2004 12:03:59 -0400 In-Reply-To: <6.0.1.1.0.20040411121900.04ad5490@127.0.0.1> (Kurt D. Zeilenga's message of "Sun, 11 Apr 2004 14:00:12 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> As I noted in my response, we use often use the terms based Kurt> on "to authenticate" to mean "to login" instead of "to Kurt> verify". I think the "A"authentication in SASL is commonly Kurt> used in the "to login" fashion. Kurt> rfc2222bis needs to be more clear here, as it is dangerous Kurt> to say things are "authenticated" when they are not Kurt> "verified". With my security hat on, I have to disagree. Not verified at all is just one point along the continuum of verification. The security difference between not verified and poorly verified is not particularly significant. I'm going to try and say less on this issue as making a consensus call is already going to be challenging. From owner-ietf-sasl Mon Apr 12 10:44:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CHiPjr025026; Mon, 12 Apr 2004 10:44:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CHiPhM025025; Mon, 12 Apr 2004 10:44:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CHiORO025016 for ; Mon, 12 Apr 2004 10:44:24 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3CHiSMs073045; Mon, 12 Apr 2004 17:44:28 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040412093816.04a302e8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 12 Apr 2004 10:44:09 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> <6.0.1.1.0.20040410110652.04af8cf8@127.0.0.1> <6.0.1.1.0.20040411121900.04ad5490@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:03 AM 4/12/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> As I noted in my response, we use often use the terms based > Kurt> on "to authenticate" to mean "to login" instead of "to > Kurt> verify". I think the "A"authentication in SASL is commonly > Kurt> used in the "to login" fashion. I like to replace "to login" in the above comment with "to identify". I don't may describing ANONYMOUS mechanism as identifying the user as an anonymous user. I have a problem saying the that the ANONYMOUS verifies the user's identity is anonymous. The latter gives off a number of false impressions. It particular, the latter can be read as implying the ANONYMOUS mechanism is providing verified user identity privacy. > Kurt> rfc2222bis needs to be more clear here, as it is dangerous > Kurt> to say things are "authenticated" when they are not > Kurt> "verified". > >With my security hat on, I have to disagree. Not verified at all is >just one point along the continuum of verification. The security >difference between not verified and poorly verified is not >particularly significant. I agree to your statement as it applies to verification. I would also agree that there is wide continuum of identification. However, I disagree that the terms verification and identification are synonymous. Whether any harm can be caused to inappropriate interchange depends on the particular case. My particular gripe with rfc2222bis is not defining well its terminology and it not terrible self consistent with its use of that terminology. Kurt From owner-ietf-sasl Mon Apr 12 11:37:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CIbDaX031121; Mon, 12 Apr 2004 11:37:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CIbDE7031120; Mon, 12 Apr 2004 11:37:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CIbC1Y031111 for ; Mon, 12 Apr 2004 11:37:13 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 8C43215159C; Mon, 12 Apr 2004 14:37:16 -0400 (EDT) To: ietf-sasl@imc.org Subject: Proposed text for adaptive plaintext attacks Message-Id: <20040412183716.8C43215159C@konishi-polis.mit.edu> Date: Mon, 12 Apr 2004 14:37:16 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I propose to replace the following text in section 9: Distributed server implementations need to be careful in how they trust other parties and, in particular, authentication secrets should only be disclosed to other parties that are trusted to manage and use those secrets in manner acceptable to disclosing party. It should be noted that, where those secrets are used to provide data confidentiality protections, if a third party (other than the discloser/disclosee) has knowledge of some portion of the protected information, it can use this knowledge in an attack upon other portions of the protected information. <
> with the following text: Distributed server implementations need to be careful in how they trust other parties and, in particular, authentication secrets should only be disclosed to other parties that are trusted to manage and use those secrets in manner acceptable to disclosing party. Applications using SASL assume that SASL security layers providing confidentiality are secure even when an attacker chooses the text to be protected by the security layer. Similarly applications assume that the SASL security layer is secure even if the attacker can manipulate the ciphertext output of the security layer. With the exception of the DES modes of the digest-md5 mechanism, all SASL mechanisms standardized by the IETF are believed to meet these security assumptions. New SASL mechanisms MUST meet these assumptions. Do people feel that explicit text about security considerations of CBC belong in the base SASL specification? --Sam From owner-ietf-sasl Mon Apr 12 12:32:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CJWSiV037912; Mon, 12 Apr 2004 12:32:28 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CJWSS8037911; Mon, 12 Apr 2004 12:32:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CJWQVj037905 for ; Mon, 12 Apr 2004 12:32:27 -0700 (PDT) (envelope-from rbunch@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 PAA08768; Mon, 12 Apr 2004 15:32:28 -0400 (EDT) Message-Id: <200404121932.PAA08768@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-saslprep-08.txt Date: Mon, 12 Apr 2004 15:32:28 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : SASLprep: Stringprep profile for user names and passwords Author(s) : K. Zeilenga Filename : draft-ietf-sasl-saslprep-08.txt Pages : 6 Date : 2004-4-12 This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the 'SASLprep' profile of the 'stringprep' algorithm to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging simple user names and/or passwords. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-saslprep-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-saslprep-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-12154057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-saslprep-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-saslprep-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-12154057.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Mon Apr 12 13:14:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CKE4aW044063; Mon, 12 Apr 2004 13:14:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CKE4sr044062; Mon, 12 Apr 2004 13:14:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CKE4Qu044056 for ; Mon, 12 Apr 2004 13:14:04 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3CKE8Ms075828 for ; Mon, 12 Apr 2004 20:14:08 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040412130620.04a88b98@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 12 Apr 2004 13:13:49 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-saslprep-08.txt In-Reply-To: <200404121932.PAA08768@ietf.org> References: <200404121932.PAA08768@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: FYI, this revision addresses two issues raised during IETF Last Call. 1) The StringPrep references now points to RFC 3454. This to keep SASLprep from blocking on the StringPrep I-D. 2) The SASL reference was reclassified as Informative as the reader need not read nor understand SASL reference material to implement or make use of SASLprep. Kurt At 12:32 PM 4/12/2004, 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 : SASLprep: Stringprep profile for user names and passwords > Author(s) : K. Zeilenga > Filename : draft-ietf-sasl-saslprep-08.txt > Pages : 6 > Date : 2004-4-12 > >This document describes how to prepare Unicode strings representing > user names and passwords for comparison. The document defines the > 'SASLprep' profile of the 'stringprep' algorithm to be used for both > user names and passwords. This profile is intended to be used by > Simple Authentication and Security Layer (SASL) mechanisms (such as > PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging > simple user names and/or passwords. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-08.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-sasl-saslprep-08.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-sasl-saslprep-08.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-4-12154057.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-sasl-saslprep-08.txt > > From owner-ietf-sasl Tue Apr 13 03:53:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DAr5KK030389; Tue, 13 Apr 2004 03:53:05 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3DAr527030388; Tue, 13 Apr 2004 03:53:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DAr4Ce030369 for ; Tue, 13 Apr 2004 03:53:04 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 13 Apr 2004 11:53:01 +0100 Message-ID: <407BC68A.5070800@isode.com> Date: Tue, 13 Apr 2004 11:52:58 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Proposed text for adaptive plaintext attacks References: <20040412183716.8C43215159C@konishi-polis.mit.edu> In-Reply-To: <20040412183716.8C43215159C@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: >I propose to replace the following text in section 9: > > Distributed server implementations need to be careful in how they > trust other parties and, in particular, authentication secrets should > only be disclosed to other parties that are trusted to manage and use > those secrets in manner acceptable to disclosing party. It should be > noted that, where those secrets are used to provide data > confidentiality protections, if a third party (other than the > discloser/disclosee) has knowledge of some portion of the protected > information, it can use this knowledge in an attack upon other > portions of the protected information. > > <
on a distributed server implementation. The section also gives some > recommendations about mitigating such attacks.>> > >with the following text: > > Distributed server implementations need to be careful in how they > trust other parties and, in particular, authentication secrets should > only be disclosed to other parties that are trusted to manage and use > those secrets in manner acceptable to disclosing party. > > Applications using SASL assume that SASL security layers providing > confidentiality are secure even when an attacker chooses the text to > be protected by the security layer. Similarly applications assume > that the SASL security layer is secure even if the attacker can > manipulate the ciphertext output of the security layer. With the > exception of the DES modes of the digest-md5 mechanism, all SASL > mechanisms standardized by the IETF are believed to meet these > security assumptions. New SASL mechanisms MUST meet these assumptions. > > > > >Do people feel that explicit text about security considerations of CBC >belong in the base SASL specification? > I personally don't think that the reference to DIGEST-MD5 belongs here. This is better be addressed in DIGEST-MD5. Alexey From owner-ietf-sasl Tue Apr 13 08:51:36 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DFpaTX051741; Tue, 13 Apr 2004 08:51:36 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3DFpa9M051740; Tue, 13 Apr 2004 08:51:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-SIXTY-EIGHT.MIT.EDU [18.187.6.113]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DFpa9K051732 for ; Tue, 13 Apr 2004 08:51:36 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id E189A15159C; Tue, 13 Apr 2004 11:51:38 -0400 (EDT) To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Proposed text for adaptive plaintext attacks References: <20040412183716.8C43215159C@konishi-polis.mit.edu> <407BC68A.5070800@isode.com> From: Sam Hartman Date: Tue, 13 Apr 2004 11:51:38 -0400 In-Reply-To: <407BC68A.5070800@isode.com> (Alexey Melnikov's message of "Tue, 13 Apr 2004 11:52:58 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> I personally don't think that the reference to DIGEST-MD5 Alexey> belongs here. This is better be addressed in DIGEST-MD5. I'm OK with dropping it although I'll explain why I put it there. I believe it is important to characterize how valid a security assumption is. In reviewing the security of SASL, I'd like to know both what the security assumptions are and whether these assumptions are actually reasonable. From owner-ietf-sasl Wed Apr 21 01:25:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3L8PIiH030169; Wed, 21 Apr 2004 01:25:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3L8PIbj030167; Wed, 21 Apr 2004 01:25:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from bisrv2.bysoft-international.fr (host.68.118.23.62.rev.coltfrance.com [62.23.118.68]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3L8PGHe030128 for ; Wed, 21 Apr 2004 01:25:17 -0700 (PDT) (envelope-from cyril.drouin@bysoft.fr) Received: from CYRILBYSOFT ([192.168.2.200]) by bisrv2.bysoft-international.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JLK6LC2A; Wed, 21 Apr 2004 10:25:51 +0200 From: "Cyril Drouin - Bysoft" To: Subject: Issue with SASL/Postfix/MySQL - Nightmare for 3 DAYS :-( Date: Wed, 21 Apr 2004 10:25:12 +0200 Message-ID: <007e01c4277a$2a7dd700$c802a8c0@CyrilBysoft> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007F_01C4278A.EE06A700" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal 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_007F_01C4278A.EE06A700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have tried for 3 days now to integrate SASL/PostFix/MySQL but I can't = make it. =20 What I have done : =20 - Compile Postfix with the SALS and MySQL support : =20 make -f Makefile.init makefiles 'CCARGS=3D-DHAS_MYSQL -I/home/cyril/mysql/include -DUSE_SASL_AUTH -I/usr/local/include/sasl'=20 'AUXLIBS=3D-L/home/cyril/mysql/lib -lmysqlclient -lz -lm -L/usr/local/lib/sasl2 -lsasl2' - Compile SALS with the MySQL support : =20 env CPPFLAGS=3D"-I/usr/include/mysql" LDFLAGS=3D"-L/usr/lib/mysql -R/usr/lib/mysql" ./configure --enable-sql --with-mysql=3D/usr/lib/mysql - Create the smtpd.conf: =20 sasl_pwcheck_method: auxprop sasl_auxprop_plugin: mysql mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM mysql_user: postfix mysql_passwd: password mysql_hostnames: localhost mysql_database: users mysql_statement: SELECT crypt FROM users WHERE address =3D '%u' mysql_verbose: yes - Change my main.cf to : =20 #Authentification SASL =20 smtpd_sasl_auth_enable =3D yes smtpd_sasl2_auth_enable =3D yes broken_sasl_auth_clients =3D yes smtpd_sasl_local_domain =3D smtpd_sasl_security_options =3D noanonymous smtpd_recipient_restrictions =3D permit_sasl_authenticated, = permit_mynetworks, reject_unauth_destination What I am sure of is : - MySQL and POSTFIX integration is working as I can check the email = through pop3/imap (I am using courier-imap package) - Postfix can send message out =20 Few questions : =20 1/ When I compile sasl, I got an error saying that : =20 checking for mysql_select_db in -lmysqlclient... (cached) no configure: WARNING: MySQL library mysqlclient does not work =20 I can't figure out why I got this warning. I used the same library than = for Mysql 2/ I got nothing in maillog. how can I know if SASL is using Mysql ? = even how can I know if Postfix is using SASL ? =20 Few more details : 1/ Redhat 9 2/ Postfix version 2.0.19 =20 3/ SASL SASL2 2.1.18=20 4/ My password are encrypted in my Database=20 =20 Thanks for your answers..I am getting crazy down here with that. =20 Cyril =20 ------=_NextPart_000_007F_01C4278A.EE06A700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
I have = tried for 3=20 days now to integrate SASL/PostFix/MySQL but I can't make=20 it.
 
What I = have done=20 :
 
- = Compile Postfix=20 with the SALS and MySQL support :
 
make = -f=20 Makefile.init makefiles 'CCARGS=3D-DHAS_MYSQL = -I/home/cyril/mysql/include=20 -DUSE_SASL_AUTH -I/usr/local/include/sasl'
 'AUXLIBS=3D-L/home/cyril/mysql/lib -lmysqlclient -lz -lm=20 -L/usr/local/lib/sasl2 -lsasl2'
- = Compile SALS with=20 the MySQL support :
 
env=20 CPPFLAGS=3D"-I/usr/include/mysql" LDFLAGS=3D"-L/usr/lib/mysql=20 -R/usr/lib/mysql"
./configure --enable-sql=20 --with-mysql=3D/usr/lib/mysql
- = Create the=20 smtpd.conf:
 
sasl_pwcheck_method:=20 auxprop
sasl_auxprop_plugin: mysql
mech_list: PLAIN LOGIN CRAM-MD5 = DIGEST-MD5 NTLM
mysql_user: postfix
mysql_passwd:=20 password
mysql_hostnames:=20 localhost
mysql_database: users
mysql_statement: SELECT crypt FROM = users=20 WHERE address =3D '%u'
mysql_verbose: yes
- = Change my=20 main.cf  to :
 
#Authentification=20 SASL
 
smtpd_sasl_auth_enable =3D yes
smtpd_sasl2_auth_enable =3D=20 yes
broken_sasl_auth_clients =3D yes
smtpd_sasl_local_domain=20 =3D
smtpd_sasl_security_options =3D = noanonymous
smtpd_recipient_restrictions =3D=20 permit_sasl_authenticated, permit_mynetworks,=20 reject_unauth_destination
What I = am sure of is=20 :
- = MySQL and POSTFIX=20 integration is working as I can check the email through pop3/imap (I am = using=20 courier-imap package)
- = Postfix can send=20 message out
 
Few = questions=20 :
 
1/ When I=20 compile sasl, I got an error saying that :
 
checking for=20 mysql_select_db in -lmysqlclient... (cached) no
configure: WARNING: = MySQL=20 library mysqlclient does not work
 
I = can't figure out=20 why I got this warning. I used the same library than for Mysql
2/ I = got nothing in=20 maillog. how can I know if SASL is using Mysql ? even how can I know if = Postfix=20 is using SASL ?
 
Few = more details=20 :
1/ = Redhat=20 9
2/ Postfix=20 version 2.0.19  
3/ SASL SASL2=20 2.1.18 
4/ My password are = encrypted=20 in my Database 
 
Thanks = for your=20 answers..I am getting crazy down here with that.
 
Cyril
 
------=_NextPart_000_007F_01C4278A.EE06A700-- From owner-ietf-sasl Wed Apr 21 22:01:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3M51x09050560; Wed, 21 Apr 2004 22:01:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3M51xbT050559; Wed, 21 Apr 2004 22:01:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3M51xsL050540 for ; Wed, 21 Apr 2004 22:01:59 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3M524Ms003216 for ; Thu, 22 Apr 2004 05:02:04 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040421215045.02c94fb0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 21 Apr 2004 22:00:57 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: SASLprep examples 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: In response to IESG comments, I have prepared the following examples to be added to the I-D. Please verify correctness. Also, if you have suggestions for additional (or replacement) examples, please provide offer specifics. -- Kurt 3. Examples The following table provides examples of how various character data is transformed by SASLprep string preparation algorithm. # Input Output Comments - ----- ------ -------- 1 xy xy SOFT HYPHEN mapped to nothing 2 user user no transformation 3 USER USER case preserved, will not match #3 4 xIV output is NFKC 5 Error - prohibited character 6 Error - bidirectional check From owner-ietf-sasl Wed Apr 21 23:06:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3M660q9078246; Wed, 21 Apr 2004 23:06:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3M660fr078245; Wed, 21 Apr 2004 23:06:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3M65uVR078190 for ; Wed, 21 Apr 2004 23:05:57 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BGXLT-0000W4-00 for ; Thu, 22 Apr 2004 08:05:59 +0200 Received: from h43n3c1o273.bredband.skanova.com ([217.208.170.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Apr 2004 08:05:59 +0200 Received: from jas by h43n3c1o273.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Apr 2004 08:05:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: SASLprep examples Date: Thu, 22 Apr 2004 08:05:56 +0200 Lines: 36 Message-ID: References: <6.0.1.1.0.20040421215045.02c94fb0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h43n3c1o273.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:UDlkqFH6HI3/m7JsMlIjXYgS5VA= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > In response to IESG comments, I have prepared the following > examples to be added to the I-D. Please verify correctness. > Also, if you have suggestions for additional (or replacement) > examples, please provide offer specifics. -- Kurt > > > 3. Examples > > The following table provides examples of how various > character data is transformed by SASLprep string > preparation algorithm. > > # Input Output Comments > - ----- ------ -------- > 1 xy xy SOFT HYPHEN mapped to nothing > 2 user user no transformation > 3 USER USER case preserved, will not match #3 > 4 xIV output is NFKC Shouldn't that be 'IV'? > 5 Error - prohibited character > 6 Error - bidirectional check I think it would be useful to add a Unicode code point for a ISO-8859-1 character that is translated into ASCII as well: 8 a output is NFKC, input exists in ISO-8859-1 This was one of the problematic code points for backwards compatibility in DIGEST-MD5. Thanks, Simon From owner-ietf-sasl Thu Apr 22 04:31:09 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MBV9aj062302; Thu, 22 Apr 2004 04:31:09 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3MBV96Y062301; Thu, 22 Apr 2004 04:31:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MBV3S4062293 for ; Thu, 22 Apr 2004 04:31:06 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BGcQ4-00062g-00 for ; Thu, 22 Apr 2004 13:31:04 +0200 Received: from h43n3c1o273.bredband.skanova.com ([217.208.170.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Apr 2004 13:31:03 +0200 Received: from jas by h43n3c1o273.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Apr 2004 13:31:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: SASLprep examples Date: Thu, 22 Apr 2004 13:30:58 +0200 Lines: 9 Message-ID: References: <6.0.1.1.0.20040421215045.02c94fb0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h43n3c1o273.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:KGOMnWAEPx5S2QuPpi/HYH1Gb6M= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > 2 user user no transformation > 3 USER USER case preserved, will not match #3 Additionally, perhaps "#3" should have been "#2". Thanks, Simon From owner-ietf-sasl Thu Apr 22 16:19:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MNJWMV027353; Thu, 22 Apr 2004 16:19:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3MNJWBw027352; Thu, 22 Apr 2004 16:19:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MNJSU2027346 for ; Thu, 22 Apr 2004 16:19:29 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BGnTi-0000V3-00 for ; Fri, 23 Apr 2004 01:19:34 +0200 Received: from h43n3c1o273.bredband.skanova.com ([217.208.170.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 23 Apr 2004 01:19:34 +0200 Received: from jas by h43n3c1o273.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 23 Apr 2004 01:19:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Use of NFKC in SASLprep Date: Fri, 23 Apr 2004 01:19:30 +0200 Lines: 9 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h43n3c1o273.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:WqFBhDWsQoYNh0oxSqciVX3n+zw= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: FYI, as SASLprep is using NFKC per Unicode 3.2, you might be interested in the NFKC stability problem discussed on . The page mention a strategy to maintain stability across NFKC revisions, which might be relevant for SASLPrep. I'd be interested to hear people's opinions on the problem. Thanks, Simon From owner-ietf-sasl Thu Apr 29 05:36:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TCaj8p094967; Thu, 29 Apr 2004 05:36:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3TCajF0094966; Thu, 29 Apr 2004 05:36:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from gab54-1.com ([193.136.195.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i3TCagSJ094957 for ; Thu, 29 Apr 2004 05:36:43 -0700 (PDT) (envelope-from hartmans@mit.edu) Date: Thu, 29 Apr 2004 13:41:44 +0000 To: "Ietf-sasl" From: "Hartmans" Subject: Re: Hello Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------suvwnbmmuzujkjlrxlxy" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------suvwnbmmuzujkjlrxlxy Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------suvwnbmmuzujkjlrxlxy Content-Type: application/octet-stream; name="Alive_condom.exe" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Alive_condom.exe" TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAkAAAAKkm3RPtR7NA7UezQO1Hs0DtR7NA7kezQGNYoEBtR7NAEWehQOxHs0AqQbVA 7EezQFJpY2jtR7NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwDMD5BAAAAAAAAA AADgAA8BCwEFDABQAAAAEAAAAJAAAPDiAAAAoAAAAPAAAAAAQAAAEAAAAAIAAAQAAAAAAAAA BAAAAAAAAAAAAAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACk8wAATAIAAADwAACkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABVUFgwAAAAAACQAAAAEAAAAAAAAAACAAAAAAAAAAAAAAAAAACAAADg VVBYMQAAAAAAUAAAAKAAAABGAAAAAgAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADw AAAABgAAAEgAAAAAAAAAAAAAAAAAAEAAAMAxLjI0AFVQWCEMCQIIvyc9X9rQb57HxwAAyUIA AACSAAAmAADM////m/rJOnEqKxiQ86MrEIn8ewjaeUIXGA5z7n9eUr/9//+6+gQ6jxg5r3EW rHG/8nGP9nG36hniLTsQ8sj83P+x3d8FO3H+Jsk4vBgSpDM49vora+237yoNKgWP6gL2qhI6 BQANGX/79gd5Pg6S+to1kPoSYTT6c78GPb//vsW+DoKQATDyEi26DXe/Aqr/m697KRIGFVN5 hwL6j/gR6QWPd2/ukQIOEmpbQw4RNQ8SqrrbNnNgRmqHDnf+arf23GbiWVqlyOxH8vi32d7f if4ZkP6SFqS9Bf8Lve3BtqrLB8koDUdoJu72rdw1rQZx/PY7E/hACVEJ7z6y/Xkb+QlQpR7y qXGn9iGQ4BJj8pT9d0l5OpsGULGPC6Ef8BKDe+cWMsqxuPsSSsWpyq11f/E6jvSqkJQlDLso xH8WusGDrEWPhIfJIRmuw5ft/1Y7Gup5A/uO8VacCfL4jvtWmgd5e3gS6BLHmDgJ9hLJ/BJv 7d2R0xLYBrl5AehIQpxC9wit/f/wnFF5E/mDSA0j0QNKx9CRxP////95GsXGxInoxs6J8P67 xqGI9f78EfH+BhH91sQ6Gvj+6x7aw9FQSamQaSShf7N9Q4d7yXEi4CIGYTMFCFR63/Z7u76O 47ISdMTTj/1Zoe1znTFz//x5PP4RIEL7iBIYBnaFn9vekvgVU3AEJE29vS72dxeEQ/oTcu7A BDgYAxJi1vht4zy/BHEzwHD+wXK/hQ2y7e62CMsF9UyvCcByFXDs24W3BcC7wSiI+CgEOY8v 2LcX3NlqArmP8nD5PAdwbMQW2rn7BdwBV4wC/rX24+S6BBtPA+7Ccq9t79vdY68GDQZwDAQX kcKb61yLEBoJBfh6pHHdurdvQMruygUFGDpwI/kEBnLfPkmvYOYZcbrG+QX1Tbr8hd0tCNbi QtJ0DZ/ajPfWlq+oHQX5OP+IHJatfJj2EysFPO72F2zkwhdD6hTdEKNrvhV1sgiqkHT72tKb t7NbBcJxcblr3/6/oQvRMHGp8vkr+an2c90Fiep1thfynb527vsFP7URPqBj7Xc7kNIJDwYS 9nU7BeoXyrIsAu4GObne/crJltoa35wFGbqqTbbZ39T7qqo9eir6AAkubI9tNM/qIfIl0hH5 OgbkxqchJQ37kPtox83utpZFWOgXBajyESn2/v3od68Cifg9uP5PI/1L+F7dmQYkLu7117Kx 26x3Ez38g7wwaVqwD+yQ+DFx/KRjFyeHubNMd/gS+oCLbLEliVn4ipfNzDchNbZb4mks92Ay ez6CHa35+AgsuO6SM3rLY8AVvt0g8LqOvgN6GXd/LapLNmC/5FvB5wIYWpL7RqDqHjMkZERf t2wnIxMSreYS4pdao3zhKMZ8nD2/AIRh3he+NQsFtwANG+CQuhLjXVC2j93J/dLCFnW9/gUK vGm2zc1rnAf2APQ9vepqz9QiPx+fCj8b2Nra0uU0Gmj5Np3y7yfhwnO9RT2lHxqprckF3kNH 04GVsG6nb+7haAfeWGzuDszQFPjrYxgG1uoS5cZW9X5/c4cIMR0HjgoJy8vDrzrIM8MrAp+Q 9Bh235UboK4A2Ri4t0L0JPn59mFr3B0W+aEFHkwKqia9wdxuyxJYdxPSeumeS9ISdZqLE4Fy H3SfB7dpvXAWCPsMn9vRAgWikC7VkgdWIBmd7qFqGoVka4/DFiGe3gwK4Qi702L13MHkkPas z+e298fBd4f7Hkz5Iobme76qGtT7CdCSO8O/bgbeEAGt+BLWA/4Iv286B96gkudwuiD+kCm2 2LsxqD5G+F0Br07Kn6/kNIo+LvwSFwK5++0HmkKqNg8Rz3kC+wv6NqqzNLtl0/gXNqrn+W02 y3Lq6gXr/gXa/0LV2mfs1U9q33f0jHDghu81EpUkErTATTIPh7DvORupuLhr4hPvUv8SlwIL 9aoWmArBrbX9AfCM/w+JDATNqgblXfMHVKsJ9hJOByxZNAxcCsFRSrbTw422qsJPCi8DBhjp Dt8u71ZWurcazw6W2V5EUDUbSnnu4RjLBr9MBeWYCrbgvsjficoQEoHCfXIK9Bgm3h7uBnfJ degJXkU/bi/xWBFuObYF2I9BFSzNBwbnHwcKEjTN1A7Zy0aDqaSaDtwBBa5NiEU4W83+ei8L 942NeFRF8lAgLQZ1ZnOvytEPtE6J5Z5sjyAdsBRC+7m61/DGDUbzd7NGQz2VDjuYDHeKJoNx E6bhO1SPsIZB2WwLt9svkl43krgJIQJ1US5bY5gpshb8DS8IT8/G7hcWWy8b7rEdcUgMLP1F 1zoKRbyxv7nNBiAmqq0SoQQZ6A3MCJ89uQkP+HElf1JvTsbbl6WYEMvNMkA+KUr8f/AYCxnv QyA7GP87EeHxKWMTLbaFvPkWFLlCsEWhSf6EgqputvXYR6PMXGv7Shn1trKD6tm39j34Rbqt ULgBOHnCvyzyLtC5tp1uoHP4hbDXHJPRYhdvpCpx8iSP/LPHbtHgoLuZEqgtBs9vixU4zS4d uh6hezcCuC7OrT1/IgbSG75dgZNrXSxzfxl3d+63xRj3TwwSHRdmuEW9G/vZtor0rRsGEinM FfEkB4TaZxoHDwQzjy0dbHNhQ1MRQAw+zqVDBU6tWH498M7KjgVTEvkjFcN1jMMgcAar303h aXpuixMjVzo3PRq2yEPqIYjozw79l4VGRvkCdvxEIwwaDQzVEPSpjPThnPmSs7HOWbohY4cK obQg+JzN2MM699AgChv64CqNfZSQExreo+pvHSOIsGRxB7x7xLatv/hv1F0RDf8q6iJxNNG3 Ans7+rE7CxnGFAIFeF5aKxR7NAUhoSpCwbkmaj0uBbed1hm3u1my8nsC+sqwHv3j98m9w2Wb Ss4KGnXHv0eBWRsl0hlszrtJc1ZwEv6pws7bZssXoBLsLxMSGSefNt0vnBE098zJ1NfuPXUH uXs3ENU/yQi6ph9IORqSI2pisjtojD3EzlCoESjvmuoILIO9GhGknPsRAH66ge9LyYYal0A2 aGhAPWipXdoe0HAfnBs6nEarLTv2GwwmPvYLHslj7ne/7xBiSJi3Gkn6jWaSMmuKI98LyEfJ ESdw6gMy5naNkipnW2By5NsMIKySLVKQSJlBDi3NeTiA0Qh3SwXLY1PGsvVHGBwCi/EZLN36 3Mj6Owvu5IPpWhR4VsteB7L5sKy59XcuaCrIV8iTAy5oZ8jDADlyksg+YkVi8kpecoTIlsjA yN5AugfxbIq/ERzkJB936MgyYtjI2bySl+rIJMvVbMmTA7IIy9VsRcshB5JXfcqQyuTJK3lU ys7K1sp4ARwloRz2yDjBbsEsHS7JOBvXdW8LQfJFzzpWtyhEWQl35P6CSfn/PgpQ/37y6TZ6 l/K6WQ5Q4i0y7zB4514JCPcM9AUa2nsbFScz8Dt5C/sHeK11fBsyYGQCfwcJ2qLICT49/2uC rM7uK2+26Ak+c52/2URqFGKzvQRaVhH9NaNW8MDUsFpWDwQ9Pwi5MehCGcp3hwwR7WvtAUOQ exUGcjjVF9qmk1AFH+wK8IgZs33Jt2sMM34R21YkvmGSj0ZyQ24W6v/hwWFlyjoj4fG5XiBb K+Ic1VyYCeTyIuIPBDnv1gIG71cJj/4Pa+YLVr4klDIQMvI13w2aqkcCBWDGXjPJoiENxyMb 2UpYdYUFLU5N9se31cT2j1B4Ck7+jbGFUdSwnBUKnHsQRv2c7W+3JZ7zDLcIBxv/nPG3DAPS dM32K5xz6iHyAhzxAKIwSW8Yy2qGHgZuEt9KVMGq1MDUQnteQTHKboDL9maaBWqQ5HwsuhQL mGVbZ9QKUs/S7mPf7i/wnHm3JvsESvu3ST5idq2ruz0usfn+QCRwBVTw26vtVh5UnEsgNgMa uqYzC5LcFBpOBxi2ffVrTI3bF9ceAkJ8q+17NiijhtdYEgJGiHUmLpugOmKcEQM+swnb1gr7 qXkC5EWt1TZzT3b9jRMNYhEac4MTCUi50cJtM0t1ZO4wB1z2A7FvUptGDvbyLW92euoOA+Z0 EvAXYu5631bGHgYfXpmgULaMS5gEm376BTq5HsLIoFrZkjaMWFcC8xeIoLlsG7Kb7zb4BWyq Gq2cDa8XtnPbm8Vil/+fAxL/0w2T7h0GglLlBRPus02CqAsZai/Wks93DgkVC9YiWkjCQbYl pDc31iXcuW8M6EcSeRD2E+9mEgKCu4QWtx2NJeoJR5rLUvv4SFbu8J9LLb4FNs3kNNqPUs+7 81L25kPUsl4SFNHiBKGRDuJe4mw3SDUmW2Vfv2GE/9EPV6HWn+77+3n71H/JRua76iLYUerQ CwTcjv6fHdCPhE7zYwb5hPYS3Uo2zzzQAhj6g1+y8TRjIA477MUoxVLk69YRyBI2qh9wZuP6 VObZ1XQGeMvcR8iMlhv1qcAjHumIBFsRrofeWRruQQwLFGC+YGcS4jsVIe2z6bJtKP/8UiD4 IJw9NmtryyZx0UOaJLuZVnyGbzH9ZGgjsDB48qvPK9Mz02K4esDo4uOS+GO+XQd3Nxx6Elw4 kstXKRj0qj9TP2IK2ZLUfElt0RslqWdRjdEJ9dozZOawij+WUqljHeSwPqjC0XST8TuivdNF kO859U2y/LMUHz1IyBtxKbEpbH8GnMU5Ca2SQvH6NwchnwvB6joG0ibB6aPfyQ/Li9RY/XMe 0jLU09LHblCp5bkgjNMV6XHdUv/HIhJDcYLu+YLqqenTZmB6J7+T0q26edOVe9l1000JDZeS Jv8kHxIHnlXq/+kzLBLffR/2kg0Nqi+1jyYKxnNCGMBdwt8CDXIAC1/d0oecDSGecZHSsd74 MaydnP+1yPa4QM9athPPqlMrGsRWuAbvkxFNc1yp5Ljq7t4hTB+o7S5j7xEFyBIVG+oSVQm9 qS+EeLb/3fJo3ZsyqZe4lfuQnhIOHfB1jNv/jmMtXvAt+/WhCTenkctCfDRf0hHQHCQwYxB4 wBrdx2eL0TJhGZLKYyRzIAf2MhK1DLjP/AmOOQdMkQqB7VmSY8802LeeBJomVjAHOewluHhj YFqpe562Rw4bGg6vJpD8VI+LjBzm06HEFk3ZCJ95FhI+B7aAHpSSkUG6F1rOEpbk22RyxBoS c90MmeIcyIqZly3ZlrwMEhLgGfc0316zS/qQIwweEvXcnjrWhxpX0F8cShImCLc94FLpRMNo EjdjY9wXrxyPqhNnEjTnLN07azcOF0EtWp636ZKc3ROVks+hfy68MQ06LO7/HMj1eCGUwM+x +g8PH6qIhzE1thi3u4nfowomQ/t6RsA9uAomlZMS9k66nwfB38f/5nIJDs1GOWEHUYq+0/wm vPcTs4pN7vIAhLOduxNlbpGI4C6zd5NHmt8eLgh67ojt5OzykqnBChGeFrQ2SNe87A632uD2 IueQbXPPEeEQ0sXeIZyz8KTApqPRfD/Uw06S3tPokqYiouc+w2AV6qgHHB0l3gnb2AoHHgje 9jQHMkYfGzc83rs5Aio25Ag3ghFWQlUefDY3UXIaL/0Y+xzjLGTGNiYiqikebioeLpOdLQwi NNkT+xAN8Y3HyToR+ZE5gXdLh4+s7wQdcQpBwKyBvBCiuZ1D2TkI8Tmz3sKpmMDf2UOI8+nD oKYeOe4G2xzvET4Myl6SVvfD4Oa6QdgWmKGkXO1+FWrZYVlmGCaMGd5hsNkr7eH++6iDOgcP e/ayDujeHcxUuxSoZDYftzLbv/vOIqUkSxP+BHuC+9ePitO1bv2ejvO6eoImjwqrb/uNffbc HpYsRxI72daU7oelD/CP7W7Zi5IBYh++y97XNGLBKoZhtSD6AzZywECg2Nwj0XavZCOQJxOw ut6yuXMkG7fYHXwCWNx1f/s5kir9mgUZERw593PhwMn6kn6C+gX9eNnuaxi6BfoQpNmJj+FL FCKHD7KbdvZ4LxZ2Bv5x9OIUUfZtMT5xzyQJ3wzme5nbOSiuABHoMg3UQ6hvOfqNDgSU2Xhj 2n8IPgJ1ycY4zRj7jlR1BSMSzwokiTh9uBbb5jXYd5BhoPgBmKxaWrd6/Nzgnm3qku50RA6+ ewGxfXs/S4z9QwYtcTEZy0Wr1b9fsOd6fYHY5ITk0SIOdbJ1EugZqvbm6LfbLf+O+DIRRmZ/ IfVuOmxbBGkR7q8hZ+I7gAvy3KWfVb5d4uTfylDuwhKP+En7IvWSzV0iXkhWKAA78MG/OiVh 5XfY4Y5GX2IOH/IfDWW+Q1kriMH/qx8ubEIBnSgaJO6Q8LhXLM03iZh/vQDsHWa+Mbp4/jV4 HvWbb/Yac3qHBNqP8b4D7RqnIdUQ146gqVn0ug16BQIy24RLrvyG4KTb9K+aI5cuF0FmCrIa CoJbGYD4zbe3CJ7gBmwDjv+HEeUO8O9L0AIGFBHfEfWmK/bOykYHQ+7ORFXQzHZ2LtpZ8go5 cbDWEOoL5XZsfwlIciEloPxxjP58PgsWsAArCNym2P2aO01Bn2xf5VYBBS3Sw+4pIRGca6ba KYBEh2yFrkwNiLzs2amyg+olKNfa7rfhpj/Qa3Hvgnl7AA4viekj3nGkjkaseUbkWfyrEvAz sLChq0DxyPEleLSEXq9Bkqa+RGgDGvEp5awoQp9i4wu6/v6Y7rR1RQbL3lSdkS2WAWlv8nqk nsQ05DTP/izykvRW3xMNOCen6T6H1lWz6goB7uyGsjdSTbZuH8+6Geq6wqHTcRZprPyueycX wk3lVQdLlWSgRB+haROtRSOEUAInJFpTBToXpXkiN/ZYQLKMPogWD2Xr9O8S1NDseZEG/Sd9 ED1AlktFmeQ2KsgGi16H/+fZt4PdFurkMVosJ1VByP7Wzf1y/ZJp3hEOJmXJObGDFKFb44NJ rqqtNAXPg2y5h5YC8D5sbjzLluncf4SaBoVc8lR4CGYzWoRnnOdoxLM+ymatEnr7dQ5SaVL/ a3cBksxXbkIB+SC24zUHpNhYbbsbR3Xuz45tjPMI8Yj/E0Q8U/oZZLBYC1hnWG6xJAcJGiZb TASNYG5CHyAUHN1sHXcFwf/yGY5dmnrHYEXosM3+DcEhy91udw2fDJLBVRoT9EI2zglD/scu B+swqxXEJDz/PBHZ/////56VlN2O2p+Mn5TajoiD2sDX04fxFPNznTHuXHIfqk9M/////x9W e2aHmbrKF0oxvK+C9MblQN4BVvCgQVrbr7RQ31qG/////5xP3hVFSiO1YsO3W6fX/uRJhS4P JVDErX81Ds1pldNf/w3+/8GlQIPtMyG2+jE1pHsUSkxvicoWyUkflv////8Xf1fPw/LQ0svW 52ef6DyewK9f68SQ6xMhZCruwEMJ9vj//6XmFulU6bn1sumW+OSi9D7x0QsNfVAjNf///6Wc dekuvDl7/HArHyl6Q+mDGCvKkSYaYbxvEv///7+Uw0Ovopq2TuNbdJ5wf1K1QRY5JGRs3fy/ 0d/o6wcq43PJk0NvKy05LnmR//9/oZKckC1Ug1ciOnglrk9z67TDBt697AQ4Gv//Lf6MFmY1 RcGuzyFgXEwD8m5AnsKfxd68o7X/////XLGufG4aa98CIhgepmiy9xsfJ1BLaXZo9M0V4ZEw 0OD/////AyRnZTymlaTUduy8HEPCMsTwbFLOautB8rPoch1VX6C/wf//adQVLqicaDUnTrkd OHBFPnjYDRQo2iDF/////zk9Y6+KcAaC5PNdEwC3rvCULG+GU0moQoFlqj2FdJi0/////+lh 0UZpeux1+LFN4DYJanQ/Otdb4pDWhsWssz2RCTxb/////5cX0eR16uC9WNnOLcUZgdTEd3vg XqY+NJC4f0+Gnb6V//+N/971pynqxlf3i366Qppun/kHDJarx9WlT8M4//8b/TWlAzvsMyzI nFxU84CuKj6Yu2s5qWFkpP/b//+wwAjEfhO9cNX2VjJIQ/JXouyGMIUhOkVJnZ4t/////5rF HmqCQ/39J9YHxcBBRIMrvHwZXDrmYjRkZFH5Mq9o///W/zJP3Wcy+R6bGlZ9aJzu/YOKkbky NU9668zI/5f+/7alrkz3/XP/gT0b6WbX88wf2M3GP2oDGrai/////zsx8kG63Fvg/CE/WR+4 3+Udt8GXM27n75obKhY25gDBwdv//1IfjR0FwHHT7rFRvS5WUapyQ0p5y5P///+/EfEtZy+G KmZOvaKljIa3WGC4d0W1Yw4VRxko0RSv6v///1FVpCQd/Fiy77sG0BX32ZqzqUxltIoGpjkz O///L9CDpStVAi2bF9rNgeA1zD5Rn4k6CVJqByP4cgMv9fl97uAHRW59NqBmzeNmeUcHy3wf 024T2YWu4yUJOAYOpaRd9QMPdqQF/1gAEpAmWJgA02b711wBfCPRDf0XGPK92fn63yMiEAYR Knf9S2wKd/J6xLmP4HqEou6ceRrBFoCEfvdFMnvfF4aGyPINnpBTGczepuoF93uToyziCDyS svgCmeI34oMV7wIQU+8iXLq6yA9uFJWP7zG/4i3PmoCETSbScTa3DOwTeur7WfaKWeIDhxwj G/HiFqoVR+LY9t0BLd8O+M3db9QyDK+cO7cM8goC+/oCCmaTgvKRLRzAA0WNTeLW/AZvIrAt StQGonEl0SB6y2H/C2bUj/uxc6cKq6g2+wptSMEgo9wfsD+LZhE9o38zj0Iwm+TZBYUU9RT4 HZBCBmQU+3efpZbzjIZDz2l8N6vACZhBR+KL9rC49B36t04gEdmwizNDT0cGjCbtgjc5Vu0b IBaROHuztVNq9nybbhaL7kwXOlsRMYQ+wnw8Tez4aiR+Y3Q8DjKWGnMgrr5gA5bBBlZ5gLFH tHYRlzdAsUG2k3/RnvdWw24bqwvJPewS8BnbCbLNqFOotRAYIgwzKsL8NhRvx8pWUkfm3sVh VqxH0dGG3fkK2qyo7ovcu8WkEdrwH/6WP20L/wvr6vkCoxn5Bgle8VA9UG1DqEulcTyJbNQe Uu8GP+o8kh5rBa/5yg/zlMFDRKItcaIhSYfBCP+wCP2idH6c72cO+Xeg5q084OPsIwUFwnm+ nRfF7xQGszjbZph0qXg2xwbQtPyrL9388gT4Dbz49VKJ9U2kxdOuUJyWAqwLsHq0FXdTClfH a/uW25PDGpWqG9SqV+OcQmGs0VegfyP8gx5/ZLLtEdMQnCf8nKCcwa8IQK6Val8TBRlPPnTX zsiisY9K323ude7iQDoVsvUGX4nS2Sph1vYI+3Kxi9N5x8FIEhySjBUcxp4xiHO+iF+kFqDP DN8HxbK6kzNHIKJIDsiPCeS01iKQ+ejqZLwlrvmILALeIWBUsg+PH7KCCJsb1feIg7QZi3A2 6YeRw0PjeEIXlkrXsAk/z/gRLOAr+fVpd585u3VcCBnvrKLMx8jIQxfehcpQf/gsKns8/PkC 8bExrBK17rj5Es4pXQNhOGYUlPsLUOITdT//QkIGrEoa6e01873ECjWKFXI5yIC900OC2Wj7 dMHzPC8Ez4WMPLnFZh8ldEAMQhzpMsjJCxoLtWjkc49dxhL2kjc4lLEZsgG5wG5RdOclJwcH +roQ+pKTHOTykiQD6BLok2eH5LjGC+ZR+smnOckUB2L6F13oWS/kyBcF6AMKmD82fr4+VcnP zpunvBsvmhU4H0oCmjFrgRiHMEzBjPv2ExwbCphT6IfcETVbhnwnB2fqmqlWqEENKcqGsO6k X3kPLuSd6y8fD7UxWcVxPdipHnOxegJd7bq+nOj3DMTpxuW6kEoGhZSB+/i9uRy/+03nSczW dRikqd7qE1+dHjuWC+rSA+qsH/pLsAHtwCtz4BH9q3HdUvCXYqPyo3PjosSqJSmxQjg2c/nk q5jXKlrw7nW5/oUUWkYAE41rRTvf7bkX7ilZl0pYPf/HBQAJEm53kLtB8ARFvw1Fqm1tulWH BlEgCN4UoNIQP4m0/X8/AzxDEjedsf7xM46bBct1lmXZduyL/gUC9g7ywgzm7oSrEscjLpQT TkTZyRe/m4l/NgxU/AaP+bWFEf/X8E4Y6lvvB2v3B6n4G2wR8UPQFPH1dXQrLIuajP++luyv ZSbMpN/wiPDo9zUbtRv+3xD/5nIRr4ZZ4RpWol+7r+JKCKCogHe5ZoCF1oW/UJzoQyoGGDh5 wQOOrHsG3F1Zuo0j9JD5eQWPFx129TEK+//tv5lxJLS0S/sHwU2IzlbGyoj+xsOM3sa7B2/c aL6gjObGm4CTxtRvxqWOtnAL+PbG147y8vHwTP04Q8BQ/LlwMhE9s4cRyK59TQZMS4nJBKwr zfD8SjJJ4kbxQn7Rv/JbhvMAPTCsoGDyWyQ48lrUV/Ww/+PJmqJzCSyNUf8wEyLyBEv6YYDh QROYc9z8/Hb41goCqQL1eVnnHnuHDurdMyxEHUH0XnsvMXEM3gYGyLqPhKM2BOI/eDg39eqt MtExewPhvfAfT6R5A/+MowkJd0duw97CbWJW7P1QODUtGAgBrfgm3vEojsOoGybbWvfFkV2g rjLcEvOxK32CPK2oaQjZIpD7gzVB8BoFr+qkE64VNKdKWJhE+8mRk4cY9qDc9wF5Tsi4OvbW 6iEez6736GBeOvnclnv8dhVWgi83ipsNPJYDknLpBotKbizHqm4TXP+PCjzArUXGxqqBAhGt WfRT/QaEOJgB1X8lO4FiEaMWjzvhdd8zkBISD/BYqpmrzIBov9hsEw3x6nrCoU/X3e+A+14R CjTaDPAi6JfkWpWueK2SEgff7BM+crYlRTNhptk00AToYOFA9kf7Tdhju3Hx+rUqI+j2uLAF ty3sy0X3LSR7gchvqPbn97GivrrK2a9hGLBKlUAvpZAIx+IyAsT7EDfxpuwC4L4pqFtb12E4 yAZg7NGWAvXK8Yt46TFkxRo8/v3xtZcKvHeo1pxyUZOcewUVf+a7BpioLAkb6A34zAgWyBDc pmerC+4n+fa6kj5iPIj21wiuG+zRbkY2oh5KzPxixDw6v7YFFIDbikeln5koc5+ggxVk8Hx/ kBkPFHVP5nggBAelxH6PkrKH6zXwxmgziiO5o/HdNoHwpIMpHEjwtqBhh9CsNm85247cEQ4S rw+desTe5uuA3AaLzw18/AreyG1ucUYF8lxivBEl0TOq+VKlpAXeBYWx6vINKvTwHhsA1970 yhJnEwrzEh7zFxXmkMu+70wjBvL7Xh2QDHzwwVaqO/+BHxtxCw0iY0PGxwN/KIf4DSsantsg qEH8ZBt18Oodtm38eocbyu88EdFKwdyC3oH6SnirUjNx+Y41c+kKRjO7SsgFmjjpJb1S8M1o SqjDakLwJqE4+v5ccDDi62TaEg3zetbAQQ1ZFuZvjALl+DPo6DXGE+CjQSmsDk0dooVazgEy jXjxUc0fJBzwTqgBrnTeejGxofjZDeIRHxKS2Vi65zS/u2VaYqc5ks4P3VhyOdLsjgRfHxle giVePN2Rp6GSKVo/V6K5z/eMrcIfshJhBZ7n+UoOBEtGPSg4xmPwHoaS2rQ1pfKB53u9mUYN qwp+WXdjQFUjDUI2VkzCjcP40xKPBfCqPjXyormntiouXVKfjDODNbMKZu8MdSeyMwZv/1G1 9nfZ2LNzHf1OkmswhlJY1zKKcwOpmoYgxHpM/QRyaH9rolxUF/IE2o75vREJCLun7XDlPCKo WttIcuWGUIFn0POWEcnDBHqBof0DscdghzockvX1rBOMejEajKc5aQvO3A8YvXr60liUe2eA byN/uuu6a3mq9Uw6SRWgcvjxow2LccPB9fIgHk2MjM27utJLlO93R2OH9s31+PCv625uBMqI w43/0hHcHiaDXha4ZW1mxgXM+w7Np/5j/Lq2ZHYa8Z2RAYTGRIv7hDD1BoEUyhItMyulR2Tk 2qhDWkO6I0uxmLA8De6QZ2SQobTU8As26+bFBU+y5zDhtnoP70+XOE+FfgbY5OHDJhJ+/FwC Oc7SzDACXzyUS+RsVs8qpfyZOLEL2NMhkpUU1x0RuiN4Fhxx7yN5OPyswRE0VKlsqLpsWBcx ARHkFbbZgpspqQ6+XSSQkgH5bZKEYDb/hHY2GFIrgltuo5ENG08HbDnJw14g6+plif/YAjvs 0vn/6xOys5ktRZ4FmhhikP3FzJKWWhOYoX7RmgzPimMGPC85LIxWHP7mRoaSgyj+pqKZ5GFJ Ub1abhZCBhn2eh7szFDPvj8mKUAKYJ6RZ7pVxl7lRplaXRbLJlwwyn1R8PkWz0G8BRkTJFdd unUg3JCdT4Tez2Xme1oHZCP4aws7yCFugP5iu0tnrVECYyLskluJkun5OrZwBO0+NiIOQ6N8 nuf0T4YFOY9ykaVcD1eOaxvZXisaEBZb3giWkWVkX+FT6FerxFlG80slGOJSOKg5LphiOPB+ bfaDDEk6Et9VmES0U38SDO4BvtaWGzugCtINa3Bme1LzDgjL72zA+QuFuQ53hxJD8j4cgLNM Hp4fGqp7kHuC6upTEq+Ri7HeiJ+Krp5qikwTVZgrhlEd9fkEIdIk0og2cC33o/tR2k+hDiOw 2W3jCwSpIPInrf/g2cEWey3NijYZn+2WpdBwAAANCgFJbiB/sP//YSBkaWZmaWN1bHQgd29y bGQVbmFtZWxlv91c+3NzIHRpCBMcYW4hdG8gc3X+b3/3cnZpdhJTbywgeW91GGlsbCBiZSBt aW639tvvFS0tIEJhZzkgQXV0aE8iMjlht2/uLjA0AglHZXJtRHkufW//t+9qAAHojkCQo2yZ QABoDzgE/zUE3+0a33BAFCGKBTZsBBaxkGpk2v7/dwdBbuvxycNVi+xX/3UIX+sIR/YIgO1u /5ezBTt9DHXzX8nCCEJrT0cAEPsg349BQChok6gOcIEFcVAebu3/ZQAA6ZX+7//M/yXsYA8F KGEZGRl5JCAcGBkZGRkUEAwI8hwZGQQA/GD4MjIyMvTw6OQyMjIy4JxUWDIyMjJcYGRoMjIy MmxwdHg5NjIyfICEv4hgns/n84xgkGCUYJhgLPl8PkegYKRgqGCsYMjIyPOwYLS4vMjIyMjA xMjMycjIyNDU2Nx8Pp/fYYlwYWxhaGFkYcjY5PmoYaQFnMjIyMi0lJCMyMjIyJiwuKzIyMjI vDg0QOHIyMhEUEhMYdlkZGTkeIR8gDIyMsKXFBAI5DthMgzZYAUgZGRkZCQoLDBkZGRkNDg8 QGFmZGRESEwAAiRUQSKaqaL6HcP+9t8+EASMT8vDz9QBy8/M1Mj6AG3///+ptbyurbuov6au k5ef+p6IjJ6elpbUn4ILptn//4EMta+uqrWprtS/or/6tLe7s7QJ/v/f/rWorrW0pQ2uv6i0 v66lqb+5r6XJ1MqlzsrN375tzyCqvAqlYKXDwqUkpbe/pWu3bdjIsRgMqS+0vTkQ+c9uB6i1 RbmuDKm5sr++ych2a2c/rqy+twmsqBjLzAy19v82sTiztdetqKrXzsjL10gKvbnug5Sxs7a2 TLleX66vqreZO7Yvyxe2vhUJHLu2J+QPc68Msb61rbTIyn0sNmsAEEIKuba/uyP8P7aluQu7 rIqIlY6fmY7Dgh652MJZ+7e9qL6zHii3E8ql5GTtNrnnw6JNDLSuD/s2m6wGbLjLwssLrr7P bu3Zrbeks7m+eaq0pb6/C4O1hbylrvwMqo6jLxvWZgpSB6m+qEJhVnAr2I0ZU585tnK/n7IB v6KrrxxYwApMGCWsv53dkmeqvheiFq6zrLOoLdiH8K+p17k6vLupCBewMCu0v3J2DEStOJw1 gsweEaqcWQu20AawuyKgB5KwzdqpYmnPtYTkwN7+Fc/Jylu4o7gQrWDbgyWjvbi34a8KZd1g jaKDvdy+CdbKEbZavd6yu4UEhn0JjTossq62HSs0Tti2v3q74XkKdnhbADWor5w0w+Rk77u+ ggy0rv1CskOwCb8jzHYyCgOzy2Czqp+MLUy2MaggqWqwMxRmrdUTyIIEYcZsWA0M5wPDTKV2 trMLX0QQG5OWuarZECIZ1y5pSUsgySE6tu3Z7Ui4iL3ICanLotsOxhmUvv68vSagCgtWKgQL kjMMW5aE9q++iMeiG2mhHcYrtJxIrdLbDlsOu6IJqeG4Cy0Jkw0guSAKi5Bsa0Mizl6/GUbD yTq+Ir+1dbNvm1uCG3NUDEC8HsPcsLULJwrq6evfsBIOqqOyr8nXjUKwlmzIFEm/mq9sl4T9 C6+3/Lavmw7htbmGJKy9e6msrN2eZgw+17u1sAgP2LBIKV4NCFrhLTuqs9kO8rUNYcnN9QzF vrruMoZ1HLUJ/bth2ZI17M/PvxhCLqzYN9iWIrYMvbbDDAPPcD2po7TOBr6lStdBak28sy68 uLOMrW7ZMAnuDargLYHCZQm/7zyWNQ3WEqkItoO+CuGDwdjOv3q1h7TzQCsvOa20rafDaA6C ToKOUmzWCwaTKnsSyzgwl7MVqq3AbpBvCrSzorGsJ6Kj0Wa1hzK/uKuWvfufrP1+yKnDAw+x pc3MpcvOycwRZYM9DrNyDL7oYIcHtgy8CbOND9k3WFgcyx3LzaXKD6zWNLA7l6kohZoN9hTL vJC8iGVukmjxrnyqWNdbmD22B73PDFiuFyxzyw614wsiNQ4UTLnGo3UxweSCbkK6Wgu4Bzf6 iYOJ2hd2uUSwpmAhq7Wqtiy19mCiaEYvrMoUSW/YG1cLXeXQOBi0d6atvUsuRuEgEa2yqI+5 huRMs7eC/4HTjLCt0QqE4L8smRhCcyJ7VTirtSWcB6gSC37ijof1WQqpuL2TraOwTBjcGlSn sam2ormDVDBk7yqgu7+FBhGGCaB+tMs6tWAQDY7fadksZrAfCRUiZXHZC8lCJBIYyDK+cCsI BUqTpLIwNmkQWr9Oq88Yw4WAdKuWEazCK21tGDSkFfM+vgSG9Ya0DL+4NrAuBqgHrwouQo1l HahbnaPYthCEO/OsJLSJVoFGK8N+R2dmKpQIqPBZCxFms3e4lgpCWTaBCYulMKUBGmevQmtC 7EcRvIOZGrO5B+gXkKmSDLxgZorA9a0gZ98TtDe3x3C4GbOzCIwHThIO1s2gOqIJqckQZmzB WktkibxKe7RkB+RfFe3SFYj0ZM+jt2rwdUvWgm4JSJOpsSQF7JstC68KkDLYYI3bBrsHty8r dWseyNc8C7SuttDsIdfJCYWxgZstUGD3RLgJdyYdWFfntAuit1vy7Cz9rn6osAt1M0iWh5Yq qh0oVJhizUCf3BJqjQysDQcMGNaCOXYKzCGrLWvkb/ULSsbIlqwwGWMLvA9ePwj3t77wZWZq T0iWrLS2inwMaMGcaTwLDAsaOYK1vgkPL3LMcsELt++TrFUqORpU1VMyGqyJFnOiqAuyMGCD RRYMs46pFsO6JGMKtQkKxLKRb9+pvwzH7AXMrQ3HDqUrCLNbvkHCwwwSxw+mYRSRG4OiRrNW Fk1bSbAmNVbNp4De2RojsEezOhxdWSySRreQgFx4s/kKNL3JKTdrradBCEgrGAYmDreTORyN WVtQvGTBGQ/NDg3WkyOpeJziw1rBDAhzDK/KycJDqFUC0vbCyrQ46YLAo12uqaAzMQT+DLfI zHj4D9v/yFZ9t/qSjo6KwNXVjQDUA3vh/4mKk5+dn5bUnp/VI4qSihsT2L/9lp+TioCTHYjX l5+JiZ8jl2D/BfaVmJOWGpSfnJWIl5tbyE9gX5uMkk+dlZ+OkoG13xYTnYiPg46OrPuHsDKS opuPjpWJmZUFrbUEdsjOH1TcOxPY3beZQNeYlY4Hm5yOJ5iEbwvsl5icGJKWk5SbBitcaCFP A5SUQlsra4VCDW0DXGsnsP+pipuZn5mWj5g/nIgdDrb2IWzXvJaVjJ8+Ip5Fu4UQM5WUldb2 DSG8j5KTkVSP85ai8O4Fwp48mdcelJOOgLbRPoB3m5ibkThDjn+wwgnklJufl1l3ob3ALo1v k5wVjW07hHCdlGiZkYaJkf4LrG3PjllYioiT142V1/JTwht1mI+InRSMk4iOj9othPGAlZTP 6YmPBIwJLxCJj9fq7i2BtQubcBiq0naBbbSWUY0Yjga7bY0QKhvXU46Tqe1tCGmJXoAekZWX BtRwDGF1mcp4pcIuhNsO14hpFUZbYI2IeprmPIEVFtiZnKByNmULbUztlxqQpYE13MaT/YzT rMo2YTtheIjM1+EqLawE95eCktm90ILCEIIrRtQ01/VSO2WmbBzJjuolVtYW2pXRbJlWOLAt lBoIjkMxnj+WhQMIralAEsiPDQuEbWuXHJ3MjP8AmJ4KsKjXJwKjUGqabbn3N8cE8pydkVY0 n5QyNEYIi3tdCOuRwmDq+wghjEIPHtxWKrRCD3cCvcoK7hGVmR5GUy5LpduEiJ5buZWIj9OH FkAU2deVuFwgtTarlbF8kVzHBgkmR4+UH1fWChcInZNmCvOegLW1jpP31KPGiVsaOFMpSVOJ 0gghlQWPkhqnVitQvohbRT0LIQwatm7pjyhcYBsKk6OWdWOEtJkzY517aynZDK6UIdXnlw3X SuCXkozsuJqVYOhMSP6IBB202rbFiRXC9Yyz2oEB1gofI7fjYaKJkogmidhsw8SVaI7JLIM3 KFFqARWaI0YIy1By+WzvCOnC9oDXkSWWmY+Sm2ZaIHGemfCUcrDAlrZhjvKYINX00Y6o14p7 XNdln5bbGoUXdo03X6YFEo0b//eMbYG1nmTYm5QLQggLxzM9TVyDJNqO+1xVsFm3DbOcZpee I6XSVuAtZiEZlMwTBtoEnKA8ijU1HIW7AmRviYVSaZB0AEu0bBvCTM0k12adh6PQSimlQ5Gm QiOEhNTiEVtgJr6Hlg9F60JioWmAy4kYj2a25KKxb5YnjMcFToUF7qeNXyDgCj0ot5mTmcQE kqGMH2GVaLYwhMSQXZvjpba8QG6fgo5yKf5LtlrqpoP634nFisffaLy1haXc9waJ+rtOttFm Wtb6MaTVGYoJbgdbCiScCZCKvvqdnG1d20aKMd+WKr0LqcZWsh9pj4oOR4582m9j7I2UD71J szy/lHsJbKkZ5BxWnxjdWKFjFLaV9RW87Kn5WAMH4gcXqZuMnwaetR6ulbw0QL6TU7kCbrOJ Fsq3oJwFJgqzA/hgwv6yCIcHTrY32/oA2NvlFyOqv7b7PRc7ajL3m/1/+hr69Nvx+//2+vxY AOrrBLPvzboD2g4LG/4ebrbsZAf6yjMGKBlLNrDqBwYM7ux8I6zGoALaAIlF9iqK6jc1fcG+ lmbr/5Cs+LYt15R6GlJzmRDSOyWcTSP+R7j6AJoahyimmXrimNlg4CuklVoLqurukicvJuqS 6gAPZjllk3IDaupkQJ5tmlY+KuofEOrDQccv4/q5lp2yoK9/FBytyA3Lary7+p7GkoOO+/yt 9ySJxdK3LrYYmR+DFvpD+K2BtUbusyT6KfjOyDMqQQPQF7FOtixt21J7c/rZYJ8Iv+eZNnuE K2dN7By+wP8KWJqH9vuPvGrpeONTZJIat+oSYbOSAc/e2Q5ixwrf+t8koE/y4mrlFJJhUb25 9ykLEo36X4KepKpRySFquVEQkk28zvqINkQ92kTgV2hmE9ExVKis2tn69wPE8wYS8/qkUAXf imVGRkY2BY6ChnocgGFGcuf6////g9rL0MvVy8DLtcuuy0DLOss8yzbLKMsiy/o7ChVlAAba nHlsCUw4R9YIjoKOpW2DbZ0GlEKfCIpI2Nt7tZIF6xsJk/fwDO3rJX7ax9rYr4mlyDrYF5/k hrWpM0kat7WYkFVq6U2l0tipmaCKTGcneDKlpKmzG9gN5tyy0zl6OUPU6rLPnUGubTPSg64K WDBntjWjMZ973ecdKrQV0rgk3pvAEiVuBpvHo+uDbDdTroQSaMbHytSVNNaZa/cNd9RB0stc 9y8riNKb0pPT0yeUcB9dsLNYlU+ABge527atBJGzvFGoq57e5Oy9nYzL1g9OD8jZBjNwu4pa Ick3mYKrqxY04p+QSrScK0eJXhXnyAgtIjjdTZXv8DosFYnPQCresjtqL3+U2tJIGYsW7sMq i4+TzLhitb9sb9YEA5bGsq63tsQVgTfovAe/u77jtr/EYH+z3Qfar4qec8bVFSauu8C/VQ/A u6o6rsfas77H2FiLBuyr2NoStGgTbAWWgAG+fAqUXvuwQlsNqa6jRxLe25orCBQxqjIQBtC9 1gw/CRS1Of1nLuCirosYt7uis7ezoAw07FZUrq4sQBq0wMgTzLUyRr23iyC4u3cS5Gj2F7Vw yrS5vxMVc5e1TVusk4EVAtdKeA0+OlsJOgedK5eBA4Al2v5tu9X4qbmos6zaQTtjt1C2vR6s uNDYHZD+Qbq3g7wMi5yW1IyYiQr3Bkh6vKm1Bq41O8mYjYz+ZvwKqT12J9SNsnbBwm7tNurc 2qaJlpxGxtYGUtbKFJFCg6QQNtgt7EJZG2Tm51AKYYOwA0qsEbbKGDkt2LJCWBtCIBE2sEJX IgphIaxsLlmsUPaBSZbNCBtkA4AbHCFsQdbVTKwyAljqXoQEQgkAAZYQSGFUF3WBQApbLy1t lzSwIpm0xZIaLuTM7xK8vlOths1i1JFlIA1OoJWSImfBqVnuYUMp1KirSaCAaSFkytIte80q 8HmIhpCmH4UIPMSNqRsD0iHwgrXTIBYr0r4QiMDV4/f6+7nWaKelXd1uPu7kbdWg/ZOfjZ+I CDank7VGa82jE1fRxo4RC40jP/q/9unbg2/tZOG3k2ZwlZyOpinaVrQHprmPIgmsRWpWriGX psJJbSboxlPUlfqzBIBambe3nfrXE5KOm3mY5CmMXMBjurPWGoaOFpROPjGK/0YFuqvPsJj4 +f7//P3y0oKpUmDHh9/lMJesuSLxDXENOQdhHpWIna8Gt/3CVpe2vKi1t8DGGsQXGtbAwLne Sw7DPril0LsGK7qX7a7eHqX6/PuWnNeJQRi5RGvTbiT6j/oWojlYT4PpG0iJKxTK0QXyBucr 9Aa5ln4d7Z7XmYrW4BoMG+SKBextqGbuBY6egwc8B6VCYZGCH3B7ZqA2Wfp0iWAAItsWLLR7 p/qrgmOJiuZu0J76IY+CBV3QxqBm33BomS4b5Fq7d5KVtFwEvJtU26VogCLXmyG6B8eXwLbw lpuY+jaJa80ZbpWVnd4Nq80c3VozcJeKLH/CUvqKa61trTvXVpu/C5QamrttWxCdMLpHitSs UtaCRtspg3wt9KYY2tbcleaiiJe9plzdwje1pvrQ1NDdjWnUopt1nBfxl4mdAIkFBM2YefuC l5YenpiCBJ6fXN42fxOUmZKXnDyVnomZnFw7xMEYeQQhsV/BFXYhJ16YmFS79sF1TpYrMNSP zzWdk21u7HNEGJ5ykEDIkhqGJ8Pnvdq1nDHjtGDaCqLJna6RLEbDtmqt25Hj27gptfchtBGi qtYLBrniJ4cvjdqxn4MTNsyl7DVfLSY1rdAObC2qGU8RFMqttYkLBAqblnhopVcuVdqZCpZI FV2XXbfb2yraN59onQy0/pvTWGWLeIeOe4loJbxtMrSTHQcyjpGDrFUxCp462Be20NpZRYqY DgySGMNirYlKggA65Rkd8aipCFza3Tk4ZqLqIbuSDytgW2vvV0HNMrBLhdx2tpXdklnpgptc rGJrDSWR7YKi7azbDsIxjcOiANrsKcrmHVyIG4lHwZbdOLt+2swpEdGECe7P2qpsMD7ots2C lo98mEeqkqCtrRkPBC3DsI8aLLQTaLcjGIKUZaqFDniMS4862G5NrT6kMZLgj5gPjgoNYubs RHZSqH071jsM+p4A3dbd2gXGrebWZQDag9pDssCP2Da20sA+Cd8qkwPIDlzd1lsKvoTAWT/M atC2lQfYCC89AZcwU4EQbvQtddLZLLeG1zvA2KhR7B4gy5PXVo5aEDwVjFfWum8tXgLXroOK ZZfVsO3W6qIp1RuknsEfVqhWsNoAPwQYmgu20YOS1wB3Hkb2hrm8DxFPhsamh0bVF5bBaY7R ajQTbD8fJgABa7RQkx0seMUGLcqJ9ddqUlnh5sA5zZg4XgbaodYRV4BUeOztIHuPUZh1n8zO IiK0WLGdZQt0VGsUY06hZcEmLLAYi1VLUWAq+xTEm5tO1hpfqwO4XtXVGBeELTvQiS2xsGBv EBKV+gSe4M99bQMR1BkDxpiI78GH934JncTGHhHZa7ESxgkGFuRopa3Sxj5QiahdxGAnXLSe wBLEQKrs2KHLy3Oeigza1wkNY7M3Fg0AqBK3Lr4JtIlI0g2yhGrs0rGVCaObU5XbCq4Bayw1 /3mDbA5Bh9luVMDTDb9N2jGrxoJeHr4ZA3uZMLiE+B1bcshkFLe/jINDw94QHFzY7iDEWpkG t/q5fj1cDV45iy7BVqhC6Q2lBjBqarVkT7ybgkR2zy0WVOjqngFtCaOVuWWRaxXaHp01msER e6kaHKUIw2Ui/w6MDfuWdIoynuwA2nN1NjubBRDUfgTuZwNXseKTjIKeBEMbVpiTdiq2tFos unLaV21y4IJsdJGJToll2CFsD5iTEIrCirOGW9Zw1I2fFyMZ1AawQWuKBguwQ10OifBwIQB2 GUfXbLoFtmyDM6+JpDQ6eGSANzWXmSmbsA+Y1EW7mJMto2GPrV+chPACCEu2I/dKrh2ziCv5 lkIcnAJCnh4IxuSeodeiGy0acwA77NE3jcKGwGUhETYbu+szfiILhC0sWNIDmNRmgmIPDDVx vseTUimKHJCMpeIOqeuW1N3fMfr8pTcxE4cNNrffHKGwcEjjozGlHCFcWWhgpU6NVKUzlNxb lLK5nKW2/9IFGHAdx44XjFNta7H5+k8TiSEVmupOWINfu5YspV6eXCXcrk6wlSl8HINobqYC X4mllJw1TN2cf2aPnIABbQStnXqbB8WPk2uO3NcdnhGIRO+sxWzfs5gOa6mXU7OGn0wwNHyE pQ+l6x7WMtVaJN3eLII2WHCOgowLjE2Tu20xi0CKkIGOrj5zYJislCGJIBfkcnNvREi7mZbV Ho+K3KG2TawYjxckMoxdzBVSuT5ojqm8X7WKEEMX/ZanWsBgaKjvaETBHLmp9F45tdoihaQ3 knCobbHKp3datAIfbIP4jqonlza3j6KCrQPxbwGuv7Sjsam+cVYbtRjNu4m802jJqf8dtEZI FOv63b7diN2V3Yrv/oV2AZ/dKqndkd2D3bQLjt36pU2z/fbXlbWbSYbX0anRA5GDtP3b0jSf joZlsbWV16X6oTHiUs5PiKaApx0/a3C0iYNqRZdpsJGWqc3SNVOXUgDXxK8/Y6+ZxgoRaaep 15Hc+Rb614PXtNdQjl2h0KqR4Y71rPqg0ouAo7DUhe25ga5Sg8BvPvrDorKO7voYakNbSHGK D6bavNWE1jZTjQcIXD3WGMz6B64nUrO5q2CjW9a2+kMNvjawh21srWopyJX6QaklF6GrjGmJ vuAO3VIDVzMzioNDqjVHzQBaB4xUZI4KsFm03JqLYSxJvWW7JfoRzxE4OonIRoMKMAq+2oT6 cwFZjIpcIgAJRQILJYkD/5fLqTQBVFABR2V0TW9kdWxl2BYAy0ZpToNBE1gLgP9Qcm9jQWRk cpAP/+y3/1N5c3RlbURpEGN0b3J5JFRpY2tDb+zbFux1bnQNPEYbbWF0QQ9jbeyfWm9uZUlu ZhVpCxdXbf+E/WluZG93c0tsb2JhbEFsBmP3v22HDEYdZQtMb2FkTGlicmEmz2LJug1jJQsk TWG7Nff+cFZpZXdPZsIOzGtCea7vW/t2VG9qZGVDaDwUT3BlbtNr28FizwgzMjBy1g/N2u4B TmV4DlJldEohgN3NrWdnaWlEcoJrW/d2U3QFbmdziVMYRcVxtd3PDQ0IQXQfYnV4da39giET UG8xEIBT2iGCuwtlcAZHGp1t27b3HwkVVCFtJ2EZ4Rf2ZKJVbm3VV2FpdF3mDG+uU4AOT2Jq OxTf7S9ZC0v0FG5FeB7hdrZ0MnJlPWx1cmOYyx722QltcGkKcHkJLvZasG4KMQn8+jDbZmei R89/egzhCx+PEFR5cC9DkXNlSGEQDwz3XmobyQlDddjBCoVyqAbcSWQU17rPAhJvbW1FTMBV BHsHx0YnkHYOm3sDO68PeHLuafgP22VHQ1Vh+29saGVscG6yX1jTU1dwc2hvdBloBhu24bBk DU2ueEENWpcwQ8dNcGQTDNpCssJvHwo/YRuabO0SvlJoS3PmbqdZWkEIFmdEGRTM4d7CVkR1 OBAWDWz2ZG9FdCBLZXkOcmZzb9kO3w1UTpijnZ0gIULwHw3Jbk1vkF9iSkRDttmbHUptfV8W CeFjO4w5Rllv5GywjW2CO0lQgyZ27xizWWtRXA4vz7h2w9xsCD7GQms329YMZ/xUpYNRcqdY 30xJNjRRMQZtT25I21qHSdQ7DmppCuFpNkdH1WIAU6s0W8OjbLVCQUVuQPbYG+4/33JJQQlE dXAI2cZgbgISVIVtCfWn6dxSJzl6WFVSTESmm+S6ZW5sQGkchWg2bZ1gfXDJdGZNHTss7DRh Z1BvkP9za20ZZm2VcKQ1eneVGk/u3hxoVRuqHE9P00mQeEndbrrsa9mSAhR0QQ6MgJUuVVwR 8zZD23BublJlZMMvWZy5tu5pjGkfX7xkO0FAo7GedMD4VZidzCEMYnkOSHnpa8BQWGOAcwNr ZXS/yltuYr1yYWNjJVNBgdccd1xydHUwIxl5NvtmrnYyehRsBz75L8dgzVBFTAEEAMwPkECe NP8P4AAPAQsBBQwARFZIUPsMBwLfWA1AC24WbDkCBDMHDMDO3JLQHjQQB7O8JN4GT9Bh3F0g kMvAoAOnxPuarrABHi7DdOtCkHcX9gXrBCMgHi5yZHSD7Qqvo0YL+wwnSNli3YVAAi4mR3Vt SprucCc6VMBPBhtsgXOCAOvAc47Av9/KJxtwZA0hxgAAAAAAAAAAIAH/AABgviWgQACNvttv //9Xg83/6xCQkJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz 73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78 EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2 D4oCQogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5BwAAAIoHRyzoPAF3 94A/AHXyiweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4AwAAAiwcJwHQ8i18EjYQw pOMAAAHzUIPHCP+WgOQAAJWKB0cIwHTciflXSPKuVf+WhOQAAAnAdAeJA4PDBOvh/5aI5AAA YekEbP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAGAAAIAAAAAA AAAAAAAAAAAAAAEAAQAAADgAAIAAAAAAAAAAAAAAAAAAAAEAAAAAAFAAAACk8AAA6AIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAEAAAB4AACAAAAAAAAAAAAAAAAAAAABAAAAAACQAAAA kPMAABQAAAAAAAAAAAAAAKDAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A /wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3 d3d3AAAAAAAAAAAAB4iIiIiIhwAAAAAAAAAAAAc4iDM4iDcAAAAAAAAAAAAHs4MAA4OHAAAA AAAAAAAAB/8w/7A4hwAAAAAAAAAAAAe4D7//A4cAAAAAAAAAAAAHgL//v/A3AAAAAAAAAAAA Bw//v/+/AwAAAAAAAAAAAAf/v/+//7AAAAAAAAAAAAAHd3d3d3d3AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////// //////////////////////////////////////////////////////////////////////// ////////gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//////// //////////+IwwAAAAABAAEAICAQAAEABADoAgAAAQAAAAAAAAAAAAAAAADY9AAAgPQAAAAA AAAAAAAAAAAAAOX0AACQ9AAAAAAAAAAAAAAAAAAA8vQAAJj0AAAAAAAAAAAAAAAAAAD89AAA oPQAAAAAAAAAAAAAAAAAAAb1AACo9AAAAAAAAAAAAAAAAAAAEvUAALD0AAAAAAAAAAAAAAAA AAAe9QAAuPQAAAAAAAAAAAAAAAAAACn1AADA9AAAAAAAAAAAAAAAAAAANPUAAMj0AAAAAAAA AAAAAAAAAABA9QAA0PQAAAAAAAAAAAAAAAAAAAAAAAAAAAAATPUAAFr1AABq9QAAAAAAAHj1 AAAAAAAAhvUAAAAAAACQ9QAAAAAAAJ71AAAAAAAArvUAAAAAAAC49QAAAAAAAMz1AAAAAAAA 2PUAAAAAAADo9QAAAAAAAEtFUk5FTDMyLkRMTABhZHZhcGkzMi5kbGwAZ2RpMzIuZGxsAG9s ZTMyLmRsbABTSEVMTDMyLmRsbABzaGx3YXBpLmRsbAB1cmxtb24uZGxsAHVzZXIzMi5kbGwA d2luaW5ldC5kbGwAd3NvY2szMi5kbGwAAABMb2FkTGlicmFyeUEAAEdldFByb2NBZGRyZXNz AABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAARGVsZXRlREMAAENvSW5pdGlhbGl6ZQAA U2hlbGxFeGVjdXRlQQAAAFN0ckR1cEEAAABVUkxEb3dubG9hZFRvRmlsZUEAAHdzcHJpbnRm QQAAAEludGVybmV0T3BlbkEAAABiaW5kAAAAAAAAAAAAAAAAAAAAAAAAwwS8kil1VROPQr5o K46bcS+enmKoLQV9lHFGeg0iQXoHp4FVPDmqTEAomVSdUHolUp+gupKtSakHPiC4s6RuSqkz VAhrlELCccUiI3ZzH1uoHJwSrZObxRc9mqASjwS2NJ4cjbYUIIWeRXJIMgmstzhJipBFXEh1 nDojrYQcnMKUczN3DIvAnmICYwqfAmwSNxeYarYouwvEDMCOWQKHACvCnm+fWaicrg6upXN9 Wj6MGw92dR7CYDQgvBiLlwQ3uoOctWGCDT1egCwZAzMbC8ULr225CkuXIhCcbTE5I7tknQGJ H3OfTT+UAUBXloxlUSSloIcIimSAX8Avq30AIcQiKbvDhLHCZx8EF5lsc2WjBkpvgbhQDHkH v1QmvsdYOQa5wyFIEiJdxVGPCXYIZ7uiFzABtMAjpReKXKvCwhCFjV+gf7ObB39rYmGprp2o vJBpGbkrorwwOiNgXBxKFkFMpsCcV7A5jjBfxyCfG2cSJDYRHW/BpANRIDK8JFp+l0yHWkaN Xg8Mp51lRH5BFhcxc1FzCrMGqZ4JDTW/XmynhwxjkQhyb4Qsq5dDIhBOdgG3woEiZlo8TkEa kQilvqeYOq85Jq4ys0+vEQCEwsGMRTAFMl1uHzCJC5tcwh1rMms1w0BHOYu3J6gmoAyPulah PwuxVIhsP1+WBZYrw2hIm3ZnM6fEALo5NzBchneKsBFah2Y5uqwHbQOQS1CBFxmHQ267th2/ KlarUWVgWJVqmBIegkVWHwgvnUE8SBCVObogiMZ4gWlYTFKwhq4EolknBrt5tGKwUYsqkVh7 IpVpC1wEcAIRioOOhCwAd5ZKCpa/wpaDXHPHjqeHKGybuaa5DHgFqGfHGIaYBC3AUEevE4mR UHhFUDZlhjCVWYOFczcXUqNGwYEMkWyJlVCWQxuYAFYqboCjqBqbsi0XwsImClsvciSOlg0X sSuwk6YzpbFjNFhKvqepwAUyjy2tIopAD6WlJj9vQR5MnIcVXEMKeZBBwmGCnaCrCz0/SYt9 NGc6iFZ2HgqUwTt9GCl8F0A9EEMjBCN3FyxdfBZQHlQVrDZQZUQvThRmuaEBQwySR5WygcOZ HwefilCfvhxNU33HeyQOxFCPV0UFvyI2lzBWQKkFImjGvG9zVMB+mGh4KlKjBiUmdWhBXzII SlE+f3xUQzArmUJ/PSyiSryZlhs5Ib0pt6KDoouxal89wFMLbSm2SC+Oipw3IJ5grSF7Kmsf EY9ASlxWB6IbbrNwakeadGMFYU1CgABEnodGklCqTII/lEZ5oxueZQGsTayAlcevol67vQtd faHHNLKoAhVCjkIuoViOesNxYhuKkX2ALpuxsAsPITF/eoK+BZFQKGAVlY63ErGTZJC3hH9t vHS1QxV4e1cLYVaWfoGMXQJzbY0/r0AgmqkMMJYTRS1HJZu8OgYhbyMIaTGxFblWM5BZB1dF bSQLn4JpLbxgkRxgj5UOn5degIKkZzeDa0h9bYMvecI4Ex/BHkOxbAhAkEo1ia+bNW1aUKKE soBauZdMNr08tkcuc6F6MLJjFGQyhYaSccRIwIBvDoMYn6lmZBZ6pK1UIyoHRUcVprMJkSm6 tbmWazMMimcexJIpCBEXWAcbKQYsnUKbPMetvnkhibY4VFoqJEGtQhaTIwGyI7dcfau9Cbd1 XCYaJGWPn6IQS70UP3NPxECwLVO5ER42wZsik4BfFZusBRmYNUlFA6x3V5o+rMIEiIEdKwsI gWwgszVisEelXVZ+LYKYriQ/Pn2nGjcnhiAfsU52l2MZtII2JYU4b4C3pXhZjSw4syVxiRDE o0OprksqKG8CLaDCUGBofsdGxGcqdFIIHrmbRlUvQgC+lVOSk4mmnE6xrRxjk3Yeqll0mKuv fmZuq0ocCHiSTYUaSaQKoyFAuQBmYcSYLCctZ2J2TMWVK7ekh0NZcVOyiI9wZ0Y7N2AukyM/ BygzHbxQAqVfx74MvkO9o6erYEapWIMKTDRxsg== ----------suvwnbmmuzujkjlrxlxy-- From owner-ietf-sasl Thu Apr 29 12:53:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TJrC9X063239; Thu, 29 Apr 2004 12:53:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3TJrCbx063238; Thu, 29 Apr 2004 12:53:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TJrBO6063232 for ; Thu, 29 Apr 2004 12:53:11 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24599; Thu, 29 Apr 2004 15:53:13 -0400 (EDT) Message-Id: <200404291953.PAA24599@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-saslprep-09.txt Date: Thu, 29 Apr 2004 15:53:13 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : SASLprep: Stringprep profile for user names and passwords Author(s) : K. Zeilenga Filename : draft-ietf-sasl-saslprep-09.txt Pages : 7 Date : 2004-4-29 This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the 'SASLprep' profile of the 'stringprep' algorithm to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging simple user names and/or passwords. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-saslprep-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-saslprep-09.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-4-29154447.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-saslprep-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-saslprep-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-29154447.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Thu Apr 29 19:37:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3U2bBmL014678; Thu, 29 Apr 2004 19:37:11 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3U2bBQU014677; Thu, 29 Apr 2004 19:37:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3U2bAxm014644 for ; Thu, 29 Apr 2004 19:37:10 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3U2bCMs076296 for ; Fri, 30 Apr 2004 02:37:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040429192907.0491a928@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 29 Apr 2004 19:37:10 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-saslprep-09.txt In-Reply-To: <200404291953.PAA24599@ietf.org> References: <200404291953.PAA24599@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This revision addresses most of the comments raised by the IESG. https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1282&filename=draft-ietf-sasl-saslprep The changes include: - Added examples (typo in 3rd example, s/#3/#2/, is known) - Added a statement regarding applicability to existing specifications. - Clarified what "other handling" could be. Additionally, there is now a DISCUSS regarding the NFKC stability concern Simon raised. I will shortly post my thoughts on this concern to the list for discussion. Kurt At 12:53 PM 4/29/2004, 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 : SASLprep: Stringprep profile for user names and passwords > Author(s) : K. Zeilenga > Filename : draft-ietf-sasl-saslprep-09.txt > Pages : 7 > Date : 2004-4-29 > >This document describes how to prepare Unicode strings representing > user names and passwords for comparison. The document defines the > 'SASLprep' profile of the 'stringprep' algorithm to be used for both > user names and passwords. This profile is intended to be used by > Simple Authentication and Security Layer (SASL) mechanisms (such as > PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging > simple user names and/or passwords. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-09.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-sasl-saslprep-09.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-sasl-saslprep-09.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-4-29154447.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-sasl-saslprep-09.txt > > From owner-ietf-sasl Fri Apr 30 08:09:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UF906Q007798; Fri, 30 Apr 2004 08:09:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3UF90GQ007797; Fri, 30 Apr 2004 08:09:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UF8xTn007781 for ; Fri, 30 Apr 2004 08:08:59 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3UF8tMs086283 for ; Fri, 30 Apr 2004 15:09:00 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 30 Apr 2004 08:08:52 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Re: Use of NFKC in SASLprep 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 04:19 PM 4/22/2004, Simon wrote: >FYI, as SASLprep is using NFKC per Unicode 3.2, you might be >interested in the NFKC stability problem discussed on >. The page mention a >strategy to maintain stability across NFKC revisions, which might be >relevant for SASLPrep. >I'd be interested to hear people's opinions on the problem. Well, I concur that there is a minor inconsistency issue which *might* lead to a security issue. However, as PR-29, "we know of no realistic scenarios that would present such problems." I have no problem noting that this inconsistency issue exists and that it *might* lead to a security issue (with an informational reference to PR-29). (However, I wouldn't mind if someone suggested some wording here.) Beyond that, I don't think we should say much more. And, in particular, I don't think we should change the SASLprep algorithm based upon PR-29 suggestions as the UTC has not yet produced a corrigendum in this area. Kurt From owner-ietf-sasl Fri Apr 30 09:09:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UG9Drk018516; Fri, 30 Apr 2004 09:09:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3UG9DEK018515; Fri, 30 Apr 2004 09:09:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UG98X4018473 for ; Fri, 30 Apr 2004 09:09:09 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BJaZX-0007wT-00 for ; Fri, 30 Apr 2004 18:09:07 +0200 Received: from h21n4c2o273.bredband.skanova.com ([217.208.171.21]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 30 Apr 2004 18:09:07 +0200 Received: from jas by h21n4c2o273.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 30 Apr 2004 18:09:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Use of NFKC in SASLprep Date: Fri, 30 Apr 2004 18:09:00 +0200 Lines: 49 Message-ID: References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h21n4c2o273.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:BThZfMGjqJawEDQQtLTRa0Hbn5I= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > At 04:19 PM 4/22/2004, Simon wrote: >>FYI, as SASLprep is using NFKC per Unicode 3.2, you might be >>interested in the NFKC stability problem discussed on >>. The page mention a >>strategy to maintain stability across NFKC revisions, which might be >>relevant for SASLPrep. >>I'd be interested to hear people's opinions on the problem. > > Well, I concur that there is a minor inconsistency issue which > *might* lead to a security issue. However, as PR-29, "we know > of no realistic scenarios that would present such problems." > > I have no problem noting that this inconsistency issue exists > and that it *might* lead to a security issue (with an informational > reference to PR-29). (However, I wouldn't mind if someone suggested > some wording here.) > > Beyond that, I don't think we should say much more. And, in > particular, I don't think we should change the SASLprep algorithm > based upon PR-29 suggestions as the UTC has not yet produced a > corrigendum in this area. Do I understand correctly if this position mean that an implementation that receive U+0B47 U+0300 U+0B3E U+0323 can pick any of: 1) U+0B47 U+0300 U+0B3E U+0323 2) U+0B4B U+0300 U+0323 3) U+0B4B U+0323 U+0300 And be compliant? If not, what is the correct output? As I understand it, PR-29 was prompted by a discovery of an internal inconsistency in the NFKC specifications, not by a wish to alter an existing and implementable specification. That means that unless the inconsistency is clarified, there is no guidance on which interpretation is correct. One scenario where this issue may be realistic are computer generated passwords. In some mechanisms, all-binary passwords are now no longer possible, so instead you randomize UCS-4 code points, apply SASLPrep and perform UTF-8 encoding. Given PR-29, NFKC of such randomized passwords might not be stable or idempotent. Thanks, Simon From owner-ietf-sasl Fri Apr 30 11:00:47 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UI0lT5037293; Fri, 30 Apr 2004 11:00:47 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3UI0lsO037292; Fri, 30 Apr 2004 11:00:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UI0ip1037286 for ; Fri, 30 Apr 2004 11:00:44 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3UI0cMs089289; Fri, 30 Apr 2004 18:00:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040430094416.0498bdd8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 30 Apr 2004 11:00:35 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: Use of NFKC in SASLprep Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:09 AM 4/30/2004, Simon Josefsson wrote: >"Kurt D. Zeilenga" writes: >> At 04:19 PM 4/22/2004, Simon wrote: >>>FYI, as SASLprep is using NFKC per Unicode 3.2, you might be >>>interested in the NFKC stability problem discussed on >>>. The page mention a >>>strategy to maintain stability across NFKC revisions, which might be >>>relevant for SASLPrep. >>>I'd be interested to hear people's opinions on the problem. >> >> Well, I concur that there is a minor inconsistency issue which >> *might* lead to a security issue. However, as PR-29, "we know >> of no realistic scenarios that would present such problems." >> >> I have no problem noting that this inconsistency issue exists >> and that it *might* lead to a security issue (with an informational >> reference to PR-29). (However, I wouldn't mind if someone suggested >> some wording here.) >> >> Beyond that, I don't think we should say much more. And, in >> particular, I don't think we should change the SASLprep algorithm >> based upon PR-29 suggestions as the UTC has not yet produced a >> corrigendum in this area. > >Do I understand correctly if this position mean that an implementation >that receive U+0B47 U+0300 U+0B3E U+0323 can pick any of: > > 1) U+0B47 U+0300 U+0B3E U+0323 > 2) U+0B4B U+0300 U+0323 > 3) U+0B4B U+0323 U+0300 > >And be compliant? Until the UTC publishes a corrigendum on the matter, yes. >As I understand it, PR-29 was prompted by a discovery of an internal >inconsistency in the NFKC specifications, not by a wish to alter an >existing and implementable specification. That means that unless the >inconsistency is clarified, there is no guidance on which >interpretation is correct. It's not our place to say which interpretation of NKFC is correct. We should just note the issue and move on. As PR-29 says: the actual cases of problematic data are limited to sequences that should never occur in practice. SASLprep is good enough for Proposed Standard level. I think this is an issue which Stringprep should address in going to Draft Standard. We can then just follow whatever is done in Stringprep (when we subsequently revise for Draft Standard). >One scenario where this issue may be realistic are computer generated >passwords. I think not. Realistic password generation algorithm need to produce well-formed text. >In some mechanisms, all-binary passwords are now no longer >possible, so instead you randomize UCS-4 code points, apply SASLPrep >and perform UTF-8 encoding. A sequence of random UCS-4 code points (of any length suitable for use as a password) would likely fail SASLprep. More realistically, the randomizer would choose assigned base character code points where SASLprep(codepoint)==codepoint. That is, I think: do { password = SASLprep(randomUnicode()); // returns NULL if SASLprep fails } while password == NULL; is an unrealistic algorithm for generation of random passwords. A more realistic algorithm would be: password = randomApproproiateCodePoints() where appropriate minimally implies each code is a base character and the SASLprep of that code is itself. It's my opinion that that this issue, aside from noting its existence, should be addressed in NFKC by the UTC, then in Stringprep by the IETF, and lastly in SASLprep by this WG. But we shouldn't wait for this, we should publish what we have as being "good enough" and then revise once the upstream specifications have been appropriately revised. Kurt From owner-ietf-sasl Tue Apr 6 13:05:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36K5JPv077791; Tue, 6 Apr 2004 13:05:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36K5JKB077790; Tue, 6 Apr 2004 13:05:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36K5HEV077779 for ; Tue, 6 Apr 2004 13:05:18 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.20) id 1BAwox-00069T-4P for ietf-sasl@imc.org; Tue, 06 Apr 2004 22:05:19 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.30) id 1BAwov-0000V3-8N; Tue, 06 Apr 2004 22:05:17 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BAwou-0004jo-00; Tue, 6 Apr 2004 22:05:16 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: Half-anonymous authentication Date: Tue, 6 Apr 2004 22:05:16 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As far as I can tell, a SASL authentication method may make the authentication ID _or_ the authorization ID anonymous, but not the other one. Is that correct? Should it be correct? Non-anonymous authentication ID + anonymous authorization ID seems useful for the ANONYMOUS mechanism. Currently, servers that implement ANONYMOUS must make a special case to ensure that they don't give any access to apparently authenticated users who used this method. However, if ANONYMOUS sets the authorization ID to anonymous, servers will give anonymous access by default. That seems a lot safer, though whether it is a good idea or not depends on what the mechanism is intended to be used for. I suggested that some time ago, but got no response - it drowned in another subthread. OTOH, I can't think of a use for anonymous authentication ID with non-anonymous authorization ID, other than those which could just as well be fulfilled by setting the authentication ID as well. Like EXTERNAL. Don't know if that is any reason to forbid it, though. -- Hallvard From owner-ietf-sasl Tue Apr 6 13:25:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36KPkje079209; Tue, 6 Apr 2004 13:25:46 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36KPkpF079208; Tue, 6 Apr 2004 13:25:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36KPjVi079200 for ; Tue, 6 Apr 2004 13:25:45 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1BAx8l-0001QI-4E for ietf-sasl@imc.org; Tue, 06 Apr 2004 22:25:47 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.30) id 1BAx8f-00059P-1C for ietf-sasl@imc.org; Tue, 06 Apr 2004 22:25:41 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BAx8e-0004mI-00 for ietf-sasl@imc.org; Tue, 6 Apr 2004 22:25:40 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: Re: Half-anonymous authentication In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 6 Apr 2004 22:25:40 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Uh... OTOH, on second reading of rfc2222bis, I can't see that a mechanism may make either ID anonymous at all. It was just so "obvious" that it could do so, that I didn't notice that it couldn't. Anyway, is that intended? I wrote: > As far as I can tell, a SASL authentication method may make the > authentication ID _or_ the authorization ID anonymous, but not the > other one. Also a bit unfortunate wording. Of course it may make both non-anonymous (or anonymous?) too:-) -- Hallvard From owner-ietf-sasl Wed Apr 7 09:41:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37GfAc0010735; Wed, 7 Apr 2004 09:41:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37GfAr6010734; Wed, 7 Apr 2004 09:41:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-TWO-SIXTY-SEVEN.MIT.EDU [18.187.6.12]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37Gf9Su010722 for ; Wed, 7 Apr 2004 09:41:09 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id ACF3D15159C; Wed, 7 Apr 2004 12:41:04 -0400 (EDT) To: Hallvard B Furuseth Cc: ietf-sasl@imc.org Subject: Re: Half-anonymous authentication References: From: Sam Hartman Date: Wed, 07 Apr 2004 12:41:04 -0400 In-Reply-To: (Hallvard B. Furuseth's message of "Tue, 6 Apr 2004 22:25:40 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Hallvard" == Hallvard B Furuseth writes: Hallvard> Uh... OTOH, on second reading of rfc2222bis, I can't see Hallvard> that a mechanism may make either ID anonymous at all. Hallvard> It was just so "obvious" that it could do so, that I Hallvard> didn't notice that it couldn't. Anyway, is that Hallvard> intended? I believe the authorization ID of all users authenticated using the anonymous mechanism is the same. From owner-ietf-sasl Wed Apr 7 10:30:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37HUh4m014617; Wed, 7 Apr 2004 10:30:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37HUhbE014616; Wed, 7 Apr 2004 10:30:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37HUgDH014601 for ; Wed, 7 Apr 2004 10:30:43 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1BBGst-0006Ei-49; Wed, 07 Apr 2004 19:30:43 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.30) id 1BBGsq-0004Gy-Sh; Wed, 07 Apr 2004 19:30:40 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BBGsq-00009k-00; Wed, 7 Apr 2004 19:30:40 +0200 From: Hallvard B Furuseth Message-Id: To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: Half-anonymous authentication In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 7 Apr 2004 19:30:40 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: > >>>>> "Hallvard" == Hallvard B Furuseth writes: > > Hallvard> Uh... OTOH, on second reading of rfc2222bis, I can't see > Hallvard> that a mechanism may make either ID anonymous at all. > Hallvard> It was just so "obvious" that it could do so, that I > Hallvard> didn't notice that it couldn't. Anyway, is that > Hallvard> intended? > > I believe the authorization ID of all users authenticated using the > anonymous mechanism is the same. Not that I can see. However, Security Considerations refer to 'the anonymous user'. Looks like a good idea for the section which defines the mechanism. However, for SASL in general I was thinking of explicitly setting up the connection to have the same authorization or authentication ID as unauthenticated connections, not setting them to a special 'anonymous user'. The former is called 'anonymous' in LDAP. Sorry about bringing the term over here without explaining. -- Hallvard From owner-ietf-sasl Thu Apr 8 03:26:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38AQ4b3065140; Thu, 8 Apr 2004 03:26:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38AQ4Sf065139; Thu, 8 Apr 2004 03:26:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.svc-box.de ([66.111.56.110]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38AQ0Qh065132 for ; Thu, 8 Apr 2004 03:26:03 -0700 (PDT) (envelope-from list-ietf-sasl@mcmilk.de) Received: (qmail 32461 invoked by uid 101); 8 Apr 2004 10:26:01 -0000 Date: Thu, 8 Apr 2004 12:26:01 +0200 From: Tino Reichardt To: ietf-sasl@imc.org Subject: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Message-ID: <20040408102601.GA25498@mcmilk.de> Reply-To: Tino Reichardt Mail-Followup-To: Tino Reichardt , ietf-sasl@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello ietf-sasl list. First of all: my english isn't the best and I am new to this list. I think the draft 'The CRAM-MD5 SASL Mechanism' should not only specify the CRAM-MD5 mechanism. Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar and then specify also some other standard hash routines as SASL CRAM mechanisms: : CRAM-MD5 160bit: CRAM-SHA1 160bit: CRAM-RIPEMD-160 320bit: CRAM-RIPEMD-320 ps: The CRAM-SHA1 mechanism is already used by serveral servers and clients. references: [SHA1] http://www.itl.nist.gov/fipspubs/fip180-1.htm [RIPEMD] http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html -- regards, TR From owner-ietf-sasl Thu Apr 8 08:44:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38FiQC8091398; Thu, 8 Apr 2004 08:44:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38FiQZv091397; Thu, 8 Apr 2004 08:44:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38FiK4w091378 for ; Thu, 8 Apr 2004 08:44:25 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 8 Apr 2004 16:43:41 +0100 Message-ID: <40757325.80401@isode.com> Date: Thu, 08 Apr 2004 16:43:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tino Reichardt CC: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? References: <20040408102601.GA25498@mcmilk.de> In-Reply-To: <20040408102601.GA25498@mcmilk.de> 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: Tino Reichardt wrote: >Hello ietf-sasl list. > >First of all: my english isn't the best and I am new to this list. > >I think the draft 'The CRAM-MD5 SASL Mechanism' should not only >specify the CRAM-MD5 mechanism. >Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar >and then specify also some other standard hash routines as SASL CRAM >mechanisms: > >: CRAM-MD5 >160bit: CRAM-SHA1 >160bit: CRAM-RIPEMD-160 >320bit: CRAM-RIPEMD-320 > I am afraid documenting those is outside of the scope for this working group. However you can contact me offline if you want to document this/help out to document this. >ps: The CRAM-SHA1 mechanism is already used by serveral servers and > clients. > > >references: > >[SHA1] http://www.itl.nist.gov/fipspubs/fip180-1.htm >[RIPEMD] http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html > > Regards, Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ From owner-ietf-sasl Thu Apr 8 14:22:36 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38LMaLn011483; Thu, 8 Apr 2004 14:22:36 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38LMaEv011482; Thu, 8 Apr 2004 14:22:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38LMWhD011473 for ; Thu, 8 Apr 2004 14:22:33 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BBgym-0002OL-00 for ; Thu, 08 Apr 2004 23:22:32 +0200 Received: from h246n3c1o299.bredband.skanova.com ([217.208.174.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Apr 2004 23:22:32 +0200 Received: from jas by h246n3c1o299.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Apr 2004 23:22:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Date: Thu, 08 Apr 2004 23:22:28 +0200 Lines: 38 Message-ID: References: <20040408102601.GA25498@mcmilk.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h246n3c1o299.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:yPsGiWO39gDyhgw2Q376kQO4L8w= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tino Reichardt writes: > I think the draft 'The CRAM-MD5 SASL Mechanism' should not only > specify the CRAM-MD5 mechanism. > Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar > and then specify also some other standard hash routines as SASL CRAM > mechanisms: > > : CRAM-MD5 > 160bit: CRAM-SHA1 > 160bit: CRAM-RIPEMD-160 > 320bit: CRAM-RIPEMD-320 For what it's worth, I'm not convinced this is a good idea. Unless there is something wrong with the authentication part of CRAM-MD5, it would only decrease interoperability if variations were added. Especially considering that a stored, non-plain, password database is not compatible across hash functions. Further, I dislike SASL mechanism families. This also applies to the new GSS-API mechanisms. It is a change compared to 2222, and it makes the generic parts of a SASL library needlessly complicated (think dynamically loading the proper SASL module based on SASL mechanism name). Still, nothing prevents you from register CRAM-SHA1 at IANA, write your own specification, and using it. But, to re-iterate, I believe it isn't useful to change the current CRAM-MD5 document into a CRAM-* family. If you need a SASL mechanism that can use other hashes, have a look at GSS-*, or perhaps KERBEROS_V5. > ps: The CRAM-SHA1 mechanism is already used by serveral servers and > clients. Do you have any pointers? Thanks, Simon From owner-ietf-sasl Fri Apr 9 00:38:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i397cQGo017086; Fri, 9 Apr 2004 00:38:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i397cQqF017085; Fri, 9 Apr 2004 00:38:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.svc-box.de ([66.111.56.110]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i397c9Vw016974 for ; Fri, 9 Apr 2004 00:38:26 -0700 (PDT) (envelope-from list-ietf-sasl@mcmilk.de) Received: (qmail 21018 invoked by uid 101); 9 Apr 2004 07:38:08 -0000 Date: Fri, 9 Apr 2004 09:38:08 +0200 From: Tino Reichardt To: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Message-ID: <20040409073807.GA15126@mcmilk.de> Reply-To: Tino Reichardt Mail-Followup-To: Tino Reichardt , ietf-sasl@imc.org References: <20040408102601.GA25498@mcmilk.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * Simon Josefsson wrote: > > Tino Reichardt writes: > > > I think the draft 'The CRAM-MD5 SASL Mechanism' should not only > > specify the CRAM-MD5 mechanism. > > Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar > > and then specify also some other standard hash routines as SASL CRAM > > mechanisms: > > > > : CRAM-MD5 > > 160bit: CRAM-SHA1 > > 160bit: CRAM-RIPEMD-160 > > 320bit: CRAM-RIPEMD-320 > > For what it's worth, I'm not convinced this is a good idea. Unless > there is something wrong with the authentication part of CRAM-MD5, it > would only decrease interoperability if variations were added. > Especially considering that a stored, non-plain, password database is > not compatible across hash functions. This is true ... can you tell me applications where contexts are stored ? > > Further, I dislike SASL mechanism families. This also applies to the > new GSS-API mechanisms. It is a change compared to 2222, and it makes > the generic parts of a SASL library needlessly complicated (think > dynamically loading the proper SASL module based on SASL mechanism > name). Do you think on a special application ? Who loads what dynamically ? Adding SHA1 + RIPEMD hash algorithms to an application isn't very complex... just see [QPASSWD]. > > Still, nothing prevents you from register CRAM-SHA1 at IANA, write > your own specification, and using it. But, to re-iterate, I believe > it isn't useful to change the current CRAM-MD5 document into a CRAM-* > family. If you need a SASL mechanism that can use other hashes, have > a look at GSS-*, or perhaps KERBEROS_V5. Okay, we need for every good hash a good draft ? > > > ps: The CRAM-SHA1 mechanism is already used by serveral servers and > > clients. > > Do you have any pointers? Not much, but since it isn't mentioned in any standard: Hamster SMTP+POP3+NNTP Server/Client: http://www.tglsoft.de/misc/hamster_en.htm Cone Mail Client: http://www.courier-mta.org/cone/cone00index.html Radius Server: http://www.freeradius.org (http://www.freeradius.org/radiusd/doc/ChangeLog) also: - courier-imapd - postfix [QPASSWD] http://www.mcmilk.de/projects/qpasswd/ -- regards, TR From owner-ietf-sasl Fri Apr 9 03:54:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39AsDgI071006; Fri, 9 Apr 2004 03:54:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39AsDMO071005; Fri, 9 Apr 2004 03:54:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39As9Fr070998 for ; Fri, 9 Apr 2004 03:54:09 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BBteD-00008m-00 for ; Fri, 09 Apr 2004 12:54:09 +0200 Received: from h246n3c1o299.bredband.skanova.com ([217.208.174.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Apr 2004 12:54:09 +0200 Received: from jas by h246n3c1o299.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Apr 2004 12:54:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Date: Fri, 09 Apr 2004 12:54:05 +0200 Lines: 103 Message-ID: References: <20040408102601.GA25498@mcmilk.de> <20040409073807.GA15126@mcmilk.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h246n3c1o299.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:LICyAxXKMJ2RG80AW0HISuHUHx8= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tino Reichardt writes: > * Simon Josefsson wrote: >> >> Tino Reichardt writes: >> >> > I think the draft 'The CRAM-MD5 SASL Mechanism' should not only >> > specify the CRAM-MD5 mechanism. >> > Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar >> > and then specify also some other standard hash routines as SASL CRAM >> > mechanisms: >> > >> > : CRAM-MD5 >> > 160bit: CRAM-SHA1 >> > 160bit: CRAM-RIPEMD-160 >> > 320bit: CRAM-RIPEMD-320 >> >> For what it's worth, I'm not convinced this is a good idea. Unless >> there is something wrong with the authentication part of CRAM-MD5, it >> would only decrease interoperability if variations were added. >> Especially considering that a stored, non-plain, password database is >> not compatible across hash functions. > This is true ... can you tell me applications where contexts are > stored ? I believe Cyrus SASL has a mode in which it doesn't store plain-text passwords, only mechanism specific contexts. I'm sure other implementations can do the same. >> Further, I dislike SASL mechanism families. This also applies to the >> new GSS-API mechanisms. It is a change compared to 2222, and it makes >> the generic parts of a SASL library needlessly complicated (think >> dynamically loading the proper SASL module based on SASL mechanism >> name). > Do you think on a special application ? Who loads what dynamically ? > Adding SHA1 + RIPEMD hash algorithms to an application isn't very > complex... just see [QPASSWD]. This was a generic comment, not specific to CRAM-*. Adding code for SHA1/RIPEMD is easy, I agree. But the code that selects the proper module to implement a specific SASL mechanism, based on a family name, will be more complicated than it was in 2222. To use GSS as an example (since there is a specification for it, so we can get into details), to be flexible the SASL library would have to recognize the "GSS-" prefix, and load e.g. libgsasl-gss.so, which in turn loads the GSS implementation, iterates over all supported GSS mechanisms (which can change over time, without the SASL library knowing about it), compute the truncated MD5 and check whether it match the GSS- string. Compare this to the 2222 approach, where you load (e.g.) libgsasl-.so and that's it. One idea for solving this problem would be to make the SASL mechanism family matter purely an IETF/IANA procedural matter, and not an intrinsic part of the SASL protocol. I mean, the GSS SASL mechanism should not imply that an implementation should go through the above procedure in order to find the proper GSS mechanism to use, but that each GSS mechanism to be used within SASL is registered as such, using the truncated MD5 as the registered name, and only after that should SASL implementations be assumed to recognize it automatically. (Of course, we can't stop implementations from recognizing non-standard SASL mechanisms, perhaps by implementing the above algorithm.) >> Still, nothing prevents you from register CRAM-SHA1 at IANA, write >> your own specification, and using it. But, to re-iterate, I believe >> it isn't useful to change the current CRAM-MD5 document into a CRAM-* >> family. If you need a SASL mechanism that can use other hashes, have >> a look at GSS-*, or perhaps KERBEROS_V5. > Okay, we need for every good hash a good draft ? Yes. Or, if 2222bis is approved with SASL mechanism families, you can write a document for the entire CRAM-* family, if you make sure it doesn't collide with CRAM-MD5. >> > ps: The CRAM-SHA1 mechanism is already used by serveral servers and >> > clients. >> >> Do you have any pointers? > Not much, but since it isn't mentioned in any standard: > > Hamster SMTP+POP3+NNTP Server/Client: > http://www.tglsoft.de/misc/hamster_en.htm > > Cone Mail Client: > http://www.courier-mta.org/cone/cone00index.html > > Radius Server: > http://www.freeradius.org > (http://www.freeradius.org/radiusd/doc/ChangeLog) > > also: > - courier-imapd > - postfix > > > [QPASSWD] http://www.mcmilk.de/projects/qpasswd/ It appears as if a document describing CRAM-SHA1 would be a useful contribution. You can add a link to it on the IANA SASL page. Regards, Simon From owner-ietf-sasl Fri Apr 9 10:45:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39HjXZ0023685; Fri, 9 Apr 2004 10:45:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39HjXlg023684; Fri, 9 Apr 2004 10:45:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.svc-box.de ([66.111.56.110]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39HjVnr023678 for ; Fri, 9 Apr 2004 10:45:32 -0700 (PDT) (envelope-from list-ietf-sasl@mcmilk.de) Received: (qmail 16831 invoked by uid 101); 9 Apr 2004 17:45:34 -0000 Date: Fri, 9 Apr 2004 19:45:34 +0200 From: Tino Reichardt To: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Message-ID: <20040409174534.GA9707@mcmilk.de> Reply-To: Tino Reichardt Mail-Followup-To: Tino Reichardt , ietf-sasl@imc.org References: <20040408102601.GA25498@mcmilk.de> <20040409073807.GA15126@mcmilk.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * Simon Josefsson wrote: > > Tino Reichardt writes: > > > * Simon Josefsson wrote: > >> > >> Tino Reichardt writes: > >> > >> > I think the draft 'The CRAM-MD5 SASL Mechanism' should not only > >> > specify the CRAM-MD5 mechanism. > >> > Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar > >> > and then specify also some other standard hash routines as SASL CRAM > >> > mechanisms: > >> > > >> > : CRAM-MD5 > >> > 160bit: CRAM-SHA1 > >> > 160bit: CRAM-RIPEMD-160 > >> > 320bit: CRAM-RIPEMD-320 > >> > >> For what it's worth, I'm not convinced this is a good idea. Unless > >> there is something wrong with the authentication part of CRAM-MD5, it > >> would only decrease interoperability if variations were added. > >> Especially considering that a stored, non-plain, password database is > >> not compatible across hash functions. > > This is true ... can you tell me applications where contexts are > > stored ? > > I believe Cyrus SASL has a mode in which it doesn't store plain-text > passwords, only mechanism specific contexts. I'm sure other > implementations can do the same. Okay, but for SMTP + POP3 servers doesn't that matter, because the initial server response differs every time ... So storing contexts here, makes no sense. As far as I know - Maybe I am on the wrong track :) > > >> Further, I dislike SASL mechanism families. This also applies to the > >> new GSS-API mechanisms. It is a change compared to 2222, and it makes > >> the generic parts of a SASL library needlessly complicated (think > >> dynamically loading the proper SASL module based on SASL mechanism > >> name). > > Do you think on a special application ? Who loads what dynamically ? > > Adding SHA1 + RIPEMD hash algorithms to an application isn't very > > complex... just see [QPASSWD]. > > This was a generic comment, not specific to CRAM-*. Adding code for > SHA1/RIPEMD is easy, I agree. > > But the code that selects the proper module to implement a specific > SASL mechanism, based on a family name, will be more complicated than > it was in 2222. To use GSS as an example (since there is a > specification for it, so we can get into details), to be flexible the > SASL library would have to recognize the "GSS-" prefix, and load > e.g. libgsasl-gss.so, which in turn loads the GSS implementation, > iterates over all supported GSS mechanisms (which can change over > time, without the SASL library knowing about it), compute the > truncated MD5 and check whether it match the GSS- string. > Compare this to the 2222 approach, where you load (e.g.) > libgsasl-.so and that's it. The applications should just load what they need to support some special typ of SASL mechanism. But such a implementation can't be the reason for not specifying new mechanisms. They have to load for every new SASL mechanism another library, when it doesn't work another way. Maybe the concept of those implementations is wrong, because when I want to by a car, I don't choose the tires first and then the car, which has to fit to them. > > One idea for solving this problem would be to make the SASL mechanism > family matter purely an IETF/IANA procedural matter, and not an > intrinsic part of the SASL protocol. I mean, the GSS SASL mechanism > should not imply that an implementation should go through the above > procedure in order to find the proper GSS mechanism to use, but that > each GSS mechanism to be used within SASL is registered as such, using > the truncated MD5 as the registered name, and only after that should > SASL implementations be assumed to recognize it automatically. (Of > course, we can't stop implementations from recognizing non-standard > SASL mechanisms, perhaps by implementing the above algorithm.) Hm... > >> Still, nothing prevents you from register CRAM-SHA1 at IANA, write > >> your own specification, and using it. But, to re-iterate, I believe > >> it isn't useful to change the current CRAM-MD5 document into a CRAM-* > >> family. If you need a SASL mechanism that can use other hashes, have > >> a look at GSS-*, or perhaps KERBEROS_V5. > > Okay, we need for every good hash a good draft ? > > Yes. Or, if 2222bis is approved with SASL mechanism families, you can > write a document for the entire CRAM-* family, if you make sure it > doesn't collide with CRAM-MD5. HMAC-SHA1 and HMAC-RIPEMD is also spcified in rfc 2104. So why shouldn't CRAM-SHA1 + CRAM-RIPEMD be mentioned in a new CRAM-MD5 rfc ? Maybe the name isn't the best one than - okay :) > It appears as if a document describing CRAM-SHA1 would be a useful > contribution. You can add a link to it on the IANA SASL page. Who? -- regards, TR From owner-ietf-sasl Fri Apr 9 11:42:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39Ig4OG029316; Fri, 9 Apr 2004 11:42:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39Ig4qA029315; Fri, 9 Apr 2004 11:42:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39Ig3ZN029309 for ; Fri, 9 Apr 2004 11:42:03 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i39Ig7Ms012047; Fri, 9 Apr 2004 18:42:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040409112800.04a86188@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 09 Apr 2004 11:41:52 -0700 To: Tino Reichardt From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Cc: ietf-sasl@imc.org In-Reply-To: <20040408102601.GA25498@mcmilk.de> References: <20040408102601.GA25498@mcmilk.de> 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: Tino, The WG CRAM-MD5 work item is limited to revising the SASL CRAM-MD5 authentication mechanism. Engineering of other CRAM-based mechanisms is simply beyond the scope of the working group. I suggest you pursue the specification of other mechanisms on an individual basis. I do not that this list is an acceptable forum for review of SASL-related submissions produced by individuals (as long as such review does not impede progress on WG deliverables). Regards, Kurt (as co-chair of the SASL-WG) At 03:26 AM 4/8/2004, Tino Reichardt wrote: >Hello ietf-sasl list. > >First of all: my english isn't the best and I am new to this list. > >I think the draft 'The CRAM-MD5 SASL Mechanism' should not only >specify the CRAM-MD5 mechanism. >Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar >and then specify also some other standard hash routines as SASL CRAM >mechanisms: > >: CRAM-MD5 >160bit: CRAM-SHA1 >160bit: CRAM-RIPEMD-160 >320bit: CRAM-RIPEMD-320 > > >ps: The CRAM-SHA1 mechanism is already used by serveral servers and > clients. > > >references: > >[SHA1] http://www.itl.nist.gov/fipspubs/fip180-1.htm >[RIPEMD] http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html > > >-- >regards, TR From owner-ietf-sasl Fri Apr 9 12:41:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39Jfr6j036742; Fri, 9 Apr 2004 12:41:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39JfrPb036741; Fri, 9 Apr 2004 12:41:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39JfqjA036735 for ; Fri, 9 Apr 2004 12:41:52 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i39JfvMs013115; Fri, 9 Apr 2004 19:41:57 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040409124008.04a88ab0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 09 Apr 2004 12:41:41 -0700 To: Tino Reichardt From: "Kurt D. Zeilenga" Subject: [corrected] Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Cc: ietf-sasl@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: My previous note had a few unfortunate typos in it. This should be more clear. Sorry for any confusion. -- Kurt Tino, The SASL WG's CRAM-MD5 work item is limited to revising the SASL CRAM-MD5 authentication mechanism. Engineering of other CRAM-based mechanisms is simply beyond the scope of this working group. I suggest you pursue the specification of other mechanisms on an individual basis. I do note that this list is an acceptable forum for review of SASL-related submissions produced by individuals (as long as such review does not impede progress on WG deliverables). Regards, Kurt (as co-chair of the SASL-WG) At 03:26 AM 4/8/2004, Tino Reichardt wrote: >Hello ietf-sasl list. > >First of all: my english isn't the best and I am new to this list. > >I think the draft 'The CRAM-MD5 SASL Mechanism' should not only >specify the CRAM-MD5 mechanism. >Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar >and then specify also some other standard hash routines as SASL CRAM >mechanisms: > >: CRAM-MD5 >160bit: CRAM-SHA1 >160bit: CRAM-RIPEMD-160 >320bit: CRAM-RIPEMD-320 > > >ps: The CRAM-SHA1 mechanism is already used by serveral servers and > clients. > > >references: > >[SHA1] http://www.itl.nist.gov/fipspubs/fip180-1.htm >[RIPEMD] http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html > > >-- >regards, TR From owner-ietf-sasl Fri Apr 9 13:29:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39KTqXi042019; Fri, 9 Apr 2004 13:29:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39KTq0f042018; Fri, 9 Apr 2004 13:29:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.svc-box.de ([66.111.56.110]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39KToYJ042010 for ; Fri, 9 Apr 2004 13:29:51 -0700 (PDT) (envelope-from list-ietf-sasl@mcmilk.de) Received: (qmail 32135 invoked by uid 101); 9 Apr 2004 20:29:54 -0000 Date: Fri, 9 Apr 2004 22:29:54 +0200 From: Tino Reichardt To: ietf-sasl@imc.org Subject: Re: [corrected] Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Message-ID: <20040409202954.GA30779@mcmilk.de> Reply-To: Tino Reichardt Mail-Followup-To: Tino Reichardt , ietf-sasl@imc.org References: <6.0.1.1.0.20040409124008.04a88ab0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.1.1.0.20040409124008.04a88ab0@127.0.0.1> User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * "Kurt D. Zeilenga" wrote: > > My previous note had a few unfortunate typos in it. This should be > more clear. Sorry for any confusion. -- Kurt No problem :) > Tino, > > The SASL WG's CRAM-MD5 work item is limited to revising the SASL > CRAM-MD5 authentication mechanism. Engineering of other CRAM-based > mechanisms is simply beyond the scope of this working group. I > suggest you pursue the specification of other mechanisms on an > individual basis. Okay, I will do so. > > I do note that this list is an acceptable forum for review of > SASL-related submissions produced by individuals (as long as > such review does not impede progress on WG deliverables). Sorry, if I was to pertly :) -- regards, TR From owner-ietf-sasl Fri Apr 9 13:37:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39Kbcmv042828; Fri, 9 Apr 2004 13:37:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39Kbccp042827; Fri, 9 Apr 2004 13:37:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39KbXWA042813 for ; Fri, 9 Apr 2004 13:37:34 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BC2ks-0003Pn-00 for ; Fri, 09 Apr 2004 22:37:38 +0200 Received: from h246n3c1o299.bredband.skanova.com ([217.208.174.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Apr 2004 22:37:38 +0200 Received: from jas by h246n3c1o299.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Apr 2004 22:37:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Date: Fri, 09 Apr 2004 22:37:33 +0200 Lines: 49 Message-ID: References: <20040408102601.GA25498@mcmilk.de> <20040409073807.GA15126@mcmilk.de> <20040409174534.GA9707@mcmilk.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h246n3c1o299.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:w3uSLJKW9MRW3uxSLUDknYXVXV4= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tino Reichardt writes: >> But the code that selects the proper module to implement a specific >> SASL mechanism, based on a family name, will be more complicated than >> it was in 2222. To use GSS as an example (since there is a >> specification for it, so we can get into details), to be flexible the >> SASL library would have to recognize the "GSS-" prefix, and load >> e.g. libgsasl-gss.so, which in turn loads the GSS implementation, >> iterates over all supported GSS mechanisms (which can change over >> time, without the SASL library knowing about it), compute the >> truncated MD5 and check whether it match the GSS- string. >> Compare this to the 2222 approach, where you load (e.g.) >> libgsasl-.so and that's it. > > The applications should just load what they need to support some > special typ of SASL mechanism. But such a implementation can't be the > reason for not specifying new mechanisms. Right, the argument was a reason for not introducing SASL mechanism families at all, at least not as a protocol matter, in 2222bis. Don't take it as criticism of your idea specifically, it wasn't meant as such. Your idea just made me think of the general topic of SASL mechanism families. >> Yes. Or, if 2222bis is approved with SASL mechanism families, you can >> write a document for the entire CRAM-* family, if you make sure it >> doesn't collide with CRAM-MD5. > > HMAC-SHA1 and HMAC-RIPEMD is also spcified in rfc 2104. So why > shouldn't CRAM-SHA1 + CRAM-RIPEMD be mentioned in a new CRAM-MD5 rfc ? > Maybe the name isn't the best one than - okay :) As Kurt Zeilenga said, the agenda for CRAM-MD5 is rather limited. Delaying it further because it can be generalized, does not sound like a good idea to me. This doesn't mean you can't work on CRAM-* in parallel though, and since you quoted existing software that uses it, having it documented and registered with IANA would be a good idea. The document for CRAM-* could begin by explaining what the technical motivations for developing it was. At least I'm curious about that. (Don't you trust MD5? Is the code size of MD5 too large? Etc.) >> It appears as if a document describing CRAM-SHA1 would be a useful >> contribution. You can add a link to it on the IANA SASL page. > Who? See http://www.iana.org/assignments/sasl-mechanisms Regards, Simon From owner-ietf-sasl Fri Apr 9 13:53:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39KruoU044565; Fri, 9 Apr 2004 13:53:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39Kru6T044564; Fri, 9 Apr 2004 13:53:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39KrtTp044557 for ; Fri, 9 Apr 2004 13:53:55 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i39KrsMs014616; Fri, 9 Apr 2004 20:53:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040409134944.04aa9da0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 09 Apr 2004 13:53:39 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Family of mechanism (Was: draft-ietf-sasl-crammd5-02 / additional mechanisms ?) Cc: ietf-sasl@imc.org In-Reply-To: References: <20040408102601.GA25498@mcmilk.de> <20040409073807.GA15126@mcmilk.de> 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:54 AM 4/9/2004, Simon Josefsson wrote: >One idea for solving this problem would be to make the SASL mechanism >family matter purely an IETF/IANA procedural matter, and not an >intrinsic part of the SASL protocol. It should be clear in the revised SASL base specification, if not already so, that families of mechanisms is purely a name space matter. To the protocol, each name/mechanism is independent of all other name/mechanism pairs. Kurt From owner-ietf-sasl Fri Apr 9 17:06:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3A06RtD066022; Fri, 9 Apr 2004 17:06:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3A06RCQ066021; Fri, 9 Apr 2004 17:06:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3A06QFN066015 for ; Fri, 9 Apr 2004 17:06:26 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3A06VMs017628; Sat, 10 Apr 2004 00:06:32 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 09 Apr 2004 17:06:16 -0700 To: Sam Hartman , Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication 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 09:41 AM 4/7/2004, Sam Hartman wrote: >>>>>> "Hallvard" == Hallvard B Furuseth writes: > > Hallvard> Uh... OTOH, on second reading of rfc2222bis, I can't see > Hallvard> that a mechanism may make either ID anonymous at all. > Hallvard> It was just so "obvious" that it could do so, that I > Hallvard> didn't notice that it couldn't. Anyway, is that > Hallvard> intended? > >I believe the authorization ID of all users authenticated using the >anonymous mechanism is the same. "users authenticated using the anonymous mechanism", I think, is a odd phrase. The anonymous mechanism doesn't provide any authentication service. (Not all SASL mechanisms provide authentication services.) I also find it odd the implication (in Hallvard's comments) that an anonymous user has an established identity. I take the view that an anonymous user is one whose's identity has not been established (or is concealed). While some implementations (and maybe even some application protocols) might associate a particular identity representation to users who are anonymous (have no established identity), this by no means implies that anonymous mechanism establishes (authenticates) the identity of the user. It doesn't. Hallvard: I'm not sure what your question is (in your last response). If your asking whether SASL itself or the ANONYMOUS mechanism defines a particular identity representation to refer to anonymous users (users which have no established identity), I think the answer is no. If your asking whether SASL or ANONYMOUS explicitly provides a facility for a user to authenticate oneself and assume the authorization of an anonymous user, I think the answer is no. I note, nothing explicitly prevents application protocol specifications from providing such facilities, including by means of defining a particular identity representation to refer to users who have not established their identity. Kurt From owner-ietf-sasl Sat Apr 10 07:54:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AEs4vF039535; Sat, 10 Apr 2004 07:54:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AEs4mw039534; Sat, 10 Apr 2004 07:54:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AEs3GN039517 for ; Sat, 10 Apr 2004 07:54:03 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1BCJrq-0001j9-39; Sat, 10 Apr 2004 16:53:58 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.30) id 1BCJrm-0005NS-PM; Sat, 10 Apr 2004 16:53:54 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BCJrl-0002SW-00; Sat, 10 Apr 2004 16:53:53 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Sam Hartman , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication In-Reply-To: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sat, 10 Apr 2004 16:53:53 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >At 09:41 AM 4/7/2004, Sam Hartman wrote: > >>>>>>> "Hallvard" == Hallvard B Furuseth writes: >> >> Hallvard> Uh... OTOH, on second reading of rfc2222bis, I can't see >> Hallvard> that a mechanism may make either ID anonymous at all. >> Hallvard> It was just so "obvious" that it could do so, that I >> Hallvard> didn't notice that it couldn't. Anyway, is that >> Hallvard> intended? >> >>I believe the authorization ID of all users authenticated using the >>anonymous mechanism is the same. > > "users authenticated using the anonymous mechanism", I think, > is a odd phrase. The anonymous mechanism doesn't provide any > authentication service. (Not all SASL mechanisms provide > authentication services.) That's not what rfc2222bis says. It describes SASL mechanisms as authentication mechanisms, and describes everything about these in terms of authentication. So according to rfc2222bis, ANONYMOUS is an authentication mechanism. One which doesn't authenticate, from what you say. (BTW, note the command 'A002 AUTHENTICATE ANONYMOUS' in the example in the ANONYMOUS draft.) Anyway, at first I thought this meant the identity sent with ANONYMOUS had to be the authentication ID, but I now notice that this is wrong. However, I think the ANONYMOUS draft does need to say explicitly how it affects the authentication and authorization IDs. Also, I now wonder how clients typically implement ANONYMOUS. If they support several SASL mechanisms, do clients expect the identity to send with ANONYMOUS in the same command line option or whatever which they use for the authentication IDs for other SASL mechanisms, or do they use some other field? Anyway, > I also find it odd the implication (in Hallvard's comments) that an > anonymous user has an established identity. I take the view that an > anonymous user is one whose's identity has not been established See above. Also, Sam's statement that all ANONYMOUS users have the _same_ authorization ID, not _no_ authorization ID. Which made me realize that anonymous auth is not a SASL term, but one I'm used to from LDAP, where it means the same as no auth. OTOH, FTP (at least on Unix) implements anonymous auth the way Sam describes: A specific user on the server's system, with limited access. > (or is concealed). Oh dear. I wish you hadn't added that. Which identity do you mean? Authentication or authorization identity, after all? And who is it concealed from? The server, or other users? > Hallvard: I'm not sure what your question is (in your last > response). If your asking whether SASL itself or the > ANONYMOUS mechanism defines a particular identity representation > to refer to anonymous users (users which have no established > identity), I think the answer is no. If your asking whether > SASL or ANONYMOUS explicitly provides a facility for a user > to authenticate oneself and assume the authorization of an > anonymous user, I think the answer is no. Almost... I'm wondering if SASL even allows an authentication mechanism to revert the authentication and authorization IDs back to unauthenticated - that is, the same state as before the first authentication. But perhaps it would be problematic if the did, since it would mess up for protocols that require authentication. Maybe an 'anonymous user' is a better concept, which protocols can treat either the same way as unauthenticated or as a normal user with limited access. > I note, nothing explicitly prevents application protocol > specifications from providing such facilities, including > by means of defining a particular identity representation > to refer to users who have not established their identity. -- Hallvard From owner-ietf-sasl Sat Apr 10 09:13:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AGDuLo050600; Sat, 10 Apr 2004 09:13:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AGDuRv050599; Sat, 10 Apr 2004 09:13:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AGDteF050593 for ; Sat, 10 Apr 2004 09:13:55 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3AGDwMs032505; Sat, 10 Apr 2004 16:13:58 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 10 Apr 2004 09:12:40 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication Cc: Sam Hartman , ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@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 07:53 AM 4/10/2004, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>At 09:41 AM 4/7/2004, Sam Hartman wrote: >> >>>>>>>> "Hallvard" == Hallvard B Furuseth writes: >>> >>> Hallvard> Uh... OTOH, on second reading of rfc2222bis, I can't see >>> Hallvard> that a mechanism may make either ID anonymous at all. >>> Hallvard> It was just so "obvious" that it could do so, that I >>> Hallvard> didn't notice that it couldn't. Anyway, is that >>> Hallvard> intended? >>> >>>I believe the authorization ID of all users authenticated using the >>>anonymous mechanism is the same. >> >> "users authenticated using the anonymous mechanism", I think, >> is a odd phrase. The anonymous mechanism doesn't provide any >> authentication service. (Not all SASL mechanisms provide >> authentication services.) > >That's not what rfc2222bis says. It describes SASL mechanisms as >authentication mechanisms, and describes everything about these in terms >of authentication. Which is a problem. rfc2222bis should be likely use more generic terms, like "SASL mechanism" when referring to a SASL mechanism. >So according to rfc2222bis, ANONYMOUS is an authentication mechanism. rfc2222bis shouldn't imply that all SASL mechanisms provide authentication services. >One which doesn't authenticate, from what you say. I would hope it obvious that ANONYMOUS does not authenticate anything. >Anyway, at first I thought this meant the identity sent with ANONYMOUS >had to be the authentication ID, but I now notice that this is wrong. The only information ANONYMOUS transfers is for trace purposes. It has no semantical value to the mechanism. >However, I think the ANONYMOUS draft does need to say explicitly how it >affects the authentication and authorization IDs. How any mechanism affects authentication and authorization IDs outside of the mechanism is beyond the scope of that mechanism. It should be obvious that this mechanism does not itself establish an authentication identity nor transfer an authorization identity. However, if more clarity is needed, I would suggest replacing the paragraph: This mechanism does not provide a security layer. with: This mechanism does not establish the identity of the client (or user) nor the server (or service); does not support transfer of an authorization identity; nor provide a security layer. and relocate this paragraph more towards the top of the section. >Also, I now wonder how clients typically implement ANONYMOUS. If they >support several SASL mechanisms, do clients expect the identity to send >with ANONYMOUS in the same command line option or whatever which they >use for the authentication IDs for other SASL mechanisms, or do they use >some other field? I suggest you look at some existing implementations. But I would hope the user would not be asked or expected to provide their credentials (or portions of their credentials) when using this mechanism. >Anyway, > >> I also find it odd the implication (in Hallvard's comments) that an >> anonymous user has an established identity. I take the view that an >> anonymous user is one whose's identity has not been established > >See above. Also, Sam's statement that all ANONYMOUS users have the >_same_ authorization ID, not _no_ authorization ID. I think Sam's statement is problematic in that implies that the mechanism is establishing or authenticating the user's identity. The server might be associating an identity with anonymous users, but the server certainly is not establishing or authenticating the user's identity. >Which made me realize that anonymous auth is not a SASL term, but one I'm used to from >LDAP, where it means the same as no auth. OTOH, FTP (at least on Unix) >implements anonymous auth the way Sam describes: A specific user on the >server's system, with limited access. But it should be clear that anonymous methods in LDAP, FTP, and elsewhere are not authenticating the user's identity. >> (or is concealed). > >Oh dear. I wish you hadn't added that. RFC 2828: $ anonymous (I) The condition of having a name that is unknown or concealed. >Which identity do you mean? The identity of the user (or a user). >Authentication or authorization identity, after all? Both, as they both refer to identities of users. >And who is it concealed from? The server, or other users? In this case, they are concealed from (at least) the server. >> Hallvard: I'm not sure what your question is (in your last >> response). If your asking whether SASL itself or the >> ANONYMOUS mechanism defines a particular identity representation >> to refer to anonymous users (users which have no established >> identity), I think the answer is no. If your asking whether >> SASL or ANONYMOUS explicitly provides a facility for a user >> to authenticate oneself and assume the authorization of an >> anonymous user, I think the answer is no. > >Almost... I'm wondering if SASL even allows an authentication >mechanism to revert the authentication and authorization IDs back >to unauthenticated - that is, the same state as before the first >authentication. SASL doesn't support "revert", it supports moving to a new authorization state. That new authorization state could be an anonymous one (one where the identity of the user is not established (authenticated)). >But perhaps it would be problematic if the did, >since it would mess up for protocols that require authentication. ANONYMOUS allows protocols which previously required authentication of the user to support processing without authentication of the user. That is, it allows the "authenticate" command to be used in a fashion which doesn't actually authenticate anything. Which, BTW, >(BTW, note the command 'A002 AUTHENTICATE ANONYMOUS' in the >example in the ANONYMOUS draft.) is what's happening here. This AUTHENTICATE command does not cause anything to be authenticated. >Maybe an 'anonymous user' is a better concept, which protocols >can treat either the same way as unauthenticated or as a normal >user with limited access. > >> I note, nothing explicitly prevents application protocol >> specifications from providing such facilities, including >> by means of defining a particular identity representation >> to refer to users who have not established their identity. > >-- >Hallvard From owner-ietf-sasl Sat Apr 10 09:57:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AGvxGS056182; Sat, 10 Apr 2004 09:57:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AGvxL4056181; Sat, 10 Apr 2004 09:57:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-FIFTY-THREE.MIT.EDU [18.187.6.98]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AGvxp1056174 for ; Sat, 10 Apr 2004 09:57:59 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 90F0415159C; Sat, 10 Apr 2004 12:58:01 -0400 (EDT) To: Hallvard B Furuseth Cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> From: Sam Hartman Date: Sat, 10 Apr 2004 12:58:01 -0400 In-Reply-To: (Hallvard B. Furuseth's message of "Sat, 10 Apr 2004 16:53:53 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard> See above. Also, Sam's statement that all ANONYMOUS Hallvard> users have the _same_ authorization ID, not _no_ Hallvard> authorization ID. Which made me realize that anonymous Hallvard> auth is not a SASL term, but one I'm used to from LDAP, Hallvard> where it means the same as no auth. OTOH, FTP (at least Hallvard> on Unix) implements anonymous auth the way Sam Hallvard> describes: A specific user on the server's system, with Hallvard> limited access. I think my statement is still generally true. It may happen that the authorization ID of anonymous users is also the same as the authorization ID of users who have engaged in no authentication exchange. It may be the case (and generally is) that the authorization ID of anonymous users cannot be represented as a string transmitted over the wire. --Sam From owner-ietf-sasl Sat Apr 10 09:59:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AGxxZu056401; Sat, 10 Apr 2004 09:59:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AGxx2o056400; Sat, 10 Apr 2004 09:59:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-FIFTY-THREE.MIT.EDU [18.187.6.98]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AGxwph056394 for ; Sat, 10 Apr 2004 09:59:59 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id E78EB15159C; Sat, 10 Apr 2004 13:00:01 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> From: Sam Hartman Date: Sat, 10 Apr 2004 13:00:01 -0400 In-Reply-To: <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> (Kurt D. Zeilenga's message of "Sat, 10 Apr 2004 09:12:40 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> Which is a problem. rfc2222bis should be likely use more Kurt> generic terms, like "SASL mechanism" when referring to a Kurt> SASL mechanism. I don't tend to agree with this. IT seems that viewing anonymous authentication as authentication is a smaller change at this date than assuming not all SASL mechanisms authenticate. >From a practical standpoint, I believe they are isomorphic models. Should I would prefer to choose the model that is most consistent with our documents. --Sam From owner-ietf-sasl Sat Apr 10 10:33:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AHXcoB060233; Sat, 10 Apr 2004 10:33:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AHXc39060232; Sat, 10 Apr 2004 10:33:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AHXb2m060214 for ; Sat, 10 Apr 2004 10:33:38 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.20) id 1BCMMK-0005x6-Q8; Sat, 10 Apr 2004 19:33:36 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.30) id 1BCMMG-0002ec-6k; Sat, 10 Apr 2004 19:33:32 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BCMMF-0002pc-00; Sat, 10 Apr 2004 19:33:31 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Sam Hartman , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication In-Reply-To: <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sat, 10 Apr 2004 19:33:31 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >At 07:53 AM 4/10/2004, Hallvard B Furuseth wrote: >>Kurt D. Zeilenga writes: >>>At 09:41 AM 4/7/2004, Sam Hartman wrote: >>>>>>>>> "Hallvard" == Hallvard B Furuseth writes: >>>> >>> The anonymous mechanism doesn't provide any >>> authentication service. (Not all SASL mechanisms provide >>> authentication services.) >> >> That's not what rfc2222bis says. It describes SASL mechanisms as >> authentication mechanisms, and describes everything about these in >> terms of authentication. > > Which is a problem. rfc2222bis should be likely use more > generic terms, like "SASL mechanism" when referring to a > SASL mechanism. rfc2222 does the same thing. Did it incorrectly describe existing implementations, or were mechanisms like ANONYMOUS added later? >> One which doesn't authenticate, from what you say. > > I would hope it obvious that ANONYMOUS does not authenticate anything. If it affects the authorization or authentication IDs, it... well, un-authenticates, I suppose. If it doesn't, it seems to violate rfc2222 and rfc2222bis. >> However, I think the ANONYMOUS draft does need to say explicitly how it >> affects the authentication and authorization IDs. > > How any mechanism affects authentication and authorization IDs > outside of the mechanism is beyond the scope of that mechanism. Beyond the scope of any mechanism, I think. Correction: It needs to say which authentication and authorization IDs it _requests_. Or provides, or whatever is the correct term. Hopefully these IDs will be treated just like IDs from other SASL mechanisms. Or like no ID (unauthenticated), if that's what the mechanism requests. > It should be obvious that this mechanism does not itself > establish an authentication identity nor transfer an authorization > identity. However, if more clarity is needed, I would suggest > replacing the paragraph: > This mechanism does not provide a security layer. > with: > This mechanism does not establish the identity of the > client (or user) nor the server (or service); does not > support transfer of an authorization identity; nor > provide a security layer. I think either 'It requests anonymous authentication and authorization identities. How to treat the anonymous ID is up to the protocol or implementation.', or 'It does not affect the authentication and authorization identities'. >> Also, I now wonder how clients typically implement ANONYMOUS. If they >> support several SASL mechanisms, do clients expect the identity to send >> with ANONYMOUS in the same command line option or whatever which they >> use for the authentication IDs for other SASL mechanisms, or do they use >> some other field? > > I suggest you look at some existing implementations. I don't know where to find any... > But > I would hope the user would not be asked or expected to > provide their credentials (or portions of their credentials) > when using this mechanism. If you mean e.g. a password, I agree. However, I was thinking of clients that authenticate to the server and then grant access to something on the client side depending on whether or not authentication succeeds. Such a client must not treat the ID sent with ANONYMOUS as an authentication ID. Or it could refuse the user to specify the ANONYMOUS mechanism, of course. >>> I also find it odd the implication (in Hallvard's comments) that an >>> anonymous user has an established identity. I take the view that an >>> anonymous user is one whose's identity has not been established >> >> See above. Also, Sam's statement that all ANONYMOUS users have the >> _same_ authorization ID, not _no_ authorization ID. > > I think Sam's statement is problematic in that implies that the > mechanism is establishing or authenticating the user's identity. > The server might be associating an identity with anonymous > users, but the server certainly is not establishing > or authenticating the user's identity. I don't see why not. The user just doesn't have anything to do with any information sent in the authentication requests. Instead the user is built into the mechanism itself. Once it is established, it has the access which the server grants that user, just like with authenticated users. >> Which made me realize that anonymous auth is not a SASL term, but one >> I'm used to from LDAP, where it means the same as no auth. OTOH, FTP >> (at least on Unix) implements anonymous auth the way Sam describes: A >> specific user on the server's system, with limited access. > > But it should be clear that anonymous methods in LDAP, FTP, > and elsewhere are not authenticating the user's identity. In LDAP it does not authenticate. In FTP it does, to the server. The anonymous user has the access which the filesystem grants to a specific user on the filesystem. >>> (or is concealed). >> >> Oh dear. I wish you hadn't added that. > > RFC 2828: > $ anonymous > (I) The condition of having a name that is unknown or concealed. > >> Which identity do you mean? > > The identity of the user (or a user). > >> Authentication or authorization identity, after all? > > Both, as they both refer to identities of users. > >> And who is it concealed from? The server, or other users? > > In this case, they are concealed from (at least) the server. Uh... An authorization identity concealed to the server is not a concept I can quite wrap my head around. The server grants access based on some specific authorization identity. >>> Hallvard: I'm not sure what your question is (in your last >>> response). If your asking whether SASL itself or the >>> ANONYMOUS mechanism defines a particular identity representation >>> to refer to anonymous users (users which have no established >>> identity), I think the answer is no. If your asking whether >>> SASL or ANONYMOUS explicitly provides a facility for a user >>> to authenticate oneself and assume the authorization of an >>> anonymous user, I think the answer is no. >> >> Almost... I'm wondering if SASL even allows an authentication >> mechanism to revert the authentication and authorization IDs back >> to unauthenticated - that is, the same state as before the first >> authentication. > > SASL doesn't support "revert", it supports moving to a new > authorization state. Replace "revert" back to "unauthenticated", then. > That new authorization state could be an anonymous one (one where the > identity of the user is not established (authenticated)). I can't find any place in rfc2222bis which says so. Where? >> But perhaps it would be problematic if the did, >> since it would mess up for protocols that require authentication. > > ANONYMOUS allows protocols which previously required authentication > of the user to support processing without authentication of the > user. That is, it allows the "authenticate" command to be used > in a fashion which doesn't actually authenticate anything. -- Hallvard From owner-ietf-sasl Sat Apr 10 10:38:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AHcxXk060731; Sat, 10 Apr 2004 10:38:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AHcxx2060730; Sat, 10 Apr 2004 10:38:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AHcwvG060723 for ; Sat, 10 Apr 2004 10:38:58 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3AHd2Ms034086; Sat, 10 Apr 2004 17:39:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040410103203.04ae46b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 10 Apr 2004 10:38:45 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:58 AM 4/10/2004, Sam Hartman wrote: > Hallvard> See above. Also, Sam's statement that all ANONYMOUS > Hallvard> users have the _same_ authorization ID, not _no_ > Hallvard> authorization ID. Which made me realize that anonymous > Hallvard> auth is not a SASL term, but one I'm used to from LDAP, > Hallvard> where it means the same as no auth. OTOH, FTP (at least > Hallvard> on Unix) implements anonymous auth the way Sam > Hallvard> describes: A specific user on the server's system, with > Hallvard> limited access. > >I think my statement is still generally true. It may happen that the >authorization ID of anonymous users is also the same as the >authorization ID of users who have engaged in no authentication >exchange. But here you are talking about some authorization ID which the service merely associates with the state of being anonymous (having an unknown or concealed identity). This is quite different than saying that anonymous users have established (authenticated) THEIR identity in the service. Kurt From owner-ietf-sasl Sat Apr 10 11:09:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AI9TgW063801; Sat, 10 Apr 2004 11:09:30 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AI9Tih063800; Sat, 10 Apr 2004 11:09:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-FIFTY-THREE.MIT.EDU [18.187.6.98]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AI9TMw063794 for ; Sat, 10 Apr 2004 11:09:29 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 59F8815159C; Sat, 10 Apr 2004 14:09:29 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410103203.04ae46b8@127.0.0.1> From: Sam Hartman Date: Sat, 10 Apr 2004 14:09:29 -0400 In-Reply-To: <6.0.1.1.0.20040410103203.04ae46b8@127.0.0.1> (Kurt D. Zeilenga's message of "Sat, 10 Apr 2004 10:38:45 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> At 09:58 AM 4/10/2004, Sam Hartman wrote: Hallvard> See above. Also, Sam's statement that all ANONYMOUS Hallvard> users have the _same_ authorization ID, not _no_ Hallvard> authorization ID. Which made me realize that anonymous Hallvard> auth is not a SASL term, but one I'm used to from LDAP, Hallvard> where it means the same as no auth. OTOH, FTP (at least Hallvard> on Unix) implements anonymous auth the way Sam Hallvard> describes: A specific user on the server's system, with Hallvard> limited access. >> I think my statement is still generally true. It may happen >> that the authorization ID of anonymous users is also the same >> as the authorization ID of users who have engaged in no >> authentication exchange. Kurt> But here you are talking about some authorization ID which Kurt> the service merely associates with the state of being Kurt> anonymous (having an unknown or concealed identity). Agree.d Kurt> This Kurt> is quite different than saying that anonymous users have Kurt> established (authenticated) THEIR identity in the service. I don't see the difference. IN both cases, the identity (or non-identity) you are authorized as establishes your privileges in the system. From owner-ietf-sasl Sat Apr 10 13:04:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AK46Zf076083; Sat, 10 Apr 2004 13:04:06 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AK45GE076082; Sat, 10 Apr 2004 13:04:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AK44DP076076 for ; Sat, 10 Apr 2004 13:04:04 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3AK49Ms036300; Sat, 10 Apr 2004 20:04:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040410110652.04af8cf8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 10 Apr 2004 13:03:52 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication Cc: Sam Hartman , ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@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:33 AM 4/10/2004, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>At 07:53 AM 4/10/2004, Hallvard B Furuseth wrote: >>>Kurt D. Zeilenga writes: >>>>At 09:41 AM 4/7/2004, Sam Hartman wrote: >>>>>>>>>> "Hallvard" == Hallvard B Furuseth writes: >>>>> >>>> The anonymous mechanism doesn't provide any >>>> authentication service. (Not all SASL mechanisms provide >>>> authentication services.) >>> >>> That's not what rfc2222bis says. It describes SASL mechanisms as >>> authentication mechanisms, and describes everything about these in >>> terms of authentication. >> >> Which is a problem. rfc2222bis should be likely use more >> generic terms, like "SASL mechanism" when referring to a >> SASL mechanism. > >rfc2222 does the same thing. RFC 2222 only once used the term "authentication mechanism". This was in the security consideration section, when referring to relative strengths of various mechanisms. It failed to distinguish that some mechanisms do not provide authentication services. That should be corrected. Everywhere else in RFC 2222, RFC 2222 used generic terms. >Did it incorrectly describe existing >implementations, or were mechanisms like ANONYMOUS added later? Often one describes features of protocols based upon what purpose they generally serve even though they might not always be used for that purpose. See say "security layer" even though the feature (say data compression) may not used to provide non-security layer . The fact that we name these features as we do, it should be made clear that they do not always provide the function the names imply. This should be made clear in RFC 2222. >>> One which doesn't authenticate, from what you say. >> >> I would hope it obvious that ANONYMOUS does not authenticate anything. > >If it affects the authorization or authentication IDs, it... well, yes. >un-authenticates, I suppose. I prefer to say that the ANONYMOUS mechanism, like all mechanisms, is used to establish a new authorization state which displaces the previous authorization state. In particular, ANONYMOUS is used to establish an anonymous authorization state. That is, the purpose of ANONYMOUS is to provide access of that of a user without requiring the user to establish their identity. >If it doesn't, it seems to violate rfc2222 and rfc2222bis. I think ANONYMOUS is fairly consistent with RFC 2222 and 2222bis. I think 2222bis needs some further clarification here and there. >>> However, I think the ANONYMOUS draft does need to say explicitly how it >>> affects the authentication and authorization IDs. >> >> How any mechanism affects authentication and authorization IDs >> outside of the mechanism is beyond the scope of that mechanism. > >Beyond the scope of any mechanism, I think. > >Correction: It needs to say which authentication and authorization IDs >it _requests_. Or provides, or whatever is the correct term. Hopefully >these IDs will be treated just like IDs from other SASL mechanisms. >Or like no ID (unauthenticated), if that's what the mechanism requests. ANONYMOUS doesn't request nor provide an authentication ID nor an authorization ID. Note that there could be other mechanisms would also do not provide such IDs to the server. Consider a mechanism which only authenticated the server to the client. Anyways, I think it sufficient for the mechanism to say what it provides (no IDs in the case of ANONYMOUS). How that's used in application protocol (or implementations thereof) is simply beyond the scope of the mechanism specification. >> It should be obvious that this mechanism does not itself >> establish an authentication identity nor transfer an authorization >> identity. However, if more clarity is needed, I would suggest >> replacing the paragraph: >> This mechanism does not provide a security layer. >> with: >> This mechanism does not establish the identity of the >> client (or user) nor the server (or service); does not >> support transfer of an authorization identity; nor >> provide a security layer. > >I think either 'It requests anonymous authentication and authorization >identities. I assume It == user here. I'm describing what the mechanism establishes and not (in this paragraph) what the user may or may not request using this mechanism. >How to treat the anonymous ID is up to the protocol or >implementation.', or 'It does not affect the authentication and >authorization identities'. The latter is especially dangerous because confusing between whether we're talking about the identity established by the user through authentication, and some identity value which represents the user has not established THEIR identity through authentication. >>> Also, I now wonder how clients typically implement ANONYMOUS. If they >>> support several SASL mechanisms, do clients expect the identity to send >>> with ANONYMOUS in the same command line option or whatever which they >>> use for the authentication IDs for other SASL mechanisms, or do they use >>> some other field? >> >> I suggest you look at some existing implementations. > >I don't know where to find any... Cyrus SASL? >> But >> I would hope the user would not be asked or expected to >> provide their credentials (or portions of their credentials) >> when using this mechanism. > >If you mean e.g. a password, I agree. I mean credentials. Credentials may include many things... and generally (but not necessarily) includes a representation of the identity they are used to establish. For instance, in PLAIN, the credentials include both a representation of the user's identity and a password. The user has to know both to gain access as that user. >However, I was thinking of >clients that authenticate to the server Who are they authenticating? Themselves or whatever entity is using the client? SASL general function is to authenticate the client (or entity which is using a client) to the server. It's not to authenticate the entity using the client to the client. This is not to say that clients cannot do that, but the security considerations for using SASL in this fashion are broad and wide. >and then grant access to >something on the client side depending on whether or not authentication >succeeds. Such a client would need to treat ANONYMOUS as not establishing the user's entity. Here, at least, the client can just disallow the mechanism. A client which uses PLAIN, CRAM-MD5, etc., for such has it far worse. They need to know which user names have widely known passwords or user names are granted access regardless of what password is provided. How many PLAIN deployments out there accept any password for "anonymous"? >Such a client must not treat the ID sent with ANONYMOUS as an >authentication ID. Whether the trace information provided by the client has any semantical value to the client is beyond the scope of the mechanism. The mechanism is quite clear that the email address, if provided, as no semantical value to the mechanism and should only be used by the server for trace purposes. >Or it could refuse the user to specify the ANONYMOUS >mechanism, of course. If a client is going to use mechanisms to authorize users to access services AT the client, then it needs to understand not only the services provided by the mechanism, but protocol/implementation/deployment details of the server it using in support of user authentication to the client. >>>> I also find it odd the implication (in Hallvard's comments) that an >>>> anonymous user has an established identity. I take the view that an >>>> anonymous user is one whose's identity has not been established >>> >>> See above. Also, Sam's statement that all ANONYMOUS users have the >>> _same_ authorization ID, not _no_ authorization ID. >> >> I think Sam's statement is problematic in that implies that the >> mechanism is establishing or authenticating the user's identity. >> The server might be associating an identity with anonymous >> users, but the server certainly is not establishing >> or authenticating the user's identity. > >I don't see why not. The user just doesn't have anything to do with any >information sent in the authentication requests. Instead the user is >built into the mechanism itself. Once it is established, it has the >access which the server grants that user, just like with authenticated >users. The distinction is wether or not the mechanism is authenticating the user's identity or whether the server-side implementation of the mechanism is merely associating some identity representation that indicates that the user's identity has not been established by the mechanism. That latter is an implementation detail. >>> Which made me realize that anonymous auth is not a SASL term, but one >>> I'm used to from LDAP, where it means the same as no auth. OTOH, FTP >>> (at least on Unix) implements anonymous auth the way Sam describes: A >>> specific user on the server's system, with limited access. >> >> But it should be clear that anonymous methods in LDAP, FTP, >> and elsewhere are not authenticating the user's identity. > >In LDAP it does not authenticate. In FTP it does, to the server. The >anonymous user has the access which the filesystem grants to a specific >user on the filesystem. The problem with your statement, in my opinion, is the implication that the user's identity seeking anonymous access has THEIR identity authenticated. No, the user seeking anonymous access is asserting a well-known account name which grants access to anyone and everyone regardless of what password is provided. So, while one is going through a login process, it is an anonymous login process. That is, the user is not required to provide THEIR credentials for authentication. They are granted access without authentication of who THEY are. It should be clear in ANONYMOUS that there is no well-known identity representation transferred to obtain anonymous access nor is any particular identity representation implies to have been transferred to the server by use of ANONYMOUS. >>>> (or is concealed). >>> >>> Oh dear. I wish you hadn't added that. >> >> RFC 2828: >> $ anonymous >> (I) The condition of having a name that is unknown or concealed. >> >>> Which identity do you mean? >> >> The identity of the user (or a user). >> >>> Authentication or authorization identity, after all? >> >> Both, as they both refer to identities of users. >> >>> And who is it concealed from? The server, or other users? >> >> In this case, they are concealed from (at least) the server. > >Uh... An authorization identity concealed to the server is not >a concept I can quite wrap my head around. The server grants >access based on some specific authorization identity. Or lack thereof. But more to the point is that the authorization identity it uses is something it constructs (possible directly from information provided in the exchange). A user can be said to be anonymous to the server if the identity of THAT user (a particular user) is not known to the server. That is, the identity of the user has been concealed by the user, the client, and the choice of mechanism. Hence, where a server might associate some special authorization identity representation to all users who have not established their identity as implying that the special identity representation used by the server is authenticated or identifies the particular user. >>>> Hallvard: I'm not sure what your question is (in your last >>>> response). If your asking whether SASL itself or the >>>> ANONYMOUS mechanism defines a particular identity representation >>>> to refer to anonymous users (users which have no established >>>> identity), I think the answer is no. If your asking whether >>>> SASL or ANONYMOUS explicitly provides a facility for a user >>>> to authenticate oneself and assume the authorization of an >>>> anonymous user, I think the answer is no. >>> >>> Almost... I'm wondering if SASL even allows an authentication >>> mechanism to revert the authentication and authorization IDs back >>> to unauthenticated - that is, the same state as before the first >>> authentication. >> >> SASL doesn't support "revert", it supports moving to a new >> authorization state. > >Replace "revert" back to "unauthenticated", then. That would make even less sense: unauthenticate the authentication ID? >> That new authorization state could be an anonymous one (one where the >> identity of the user is not established (authenticated)). > >I can't find any place in rfc2222bis which says so. Where? As I said before, RFC 2222bis needs work here. A number of the clarifications added to RFC 2222bis are causing confusion. Those clarifications need refinement. From owner-ietf-sasl Sat Apr 10 13:25:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AKPY2e077843; Sat, 10 Apr 2004 13:25:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AKPYFZ077842; Sat, 10 Apr 2004 13:25:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AKPXSG077836 for ; Sat, 10 Apr 2004 13:25:34 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3AKPcMs036626; Sat, 10 Apr 2004 20:25:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040410130528.04b19dd8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 10 Apr 2004 13:25:22 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410103203.04ae46b8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:09 AM 4/10/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> At 09:58 AM 4/10/2004, Sam Hartman wrote: > Hallvard> See above. Also, Sam's statement that all ANONYMOUS > Hallvard> users have the _same_ authorization ID, not _no_ > Hallvard> authorization ID. Which made me realize that anonymous > Hallvard> auth is not a SASL term, but one I'm used to from LDAP, > Hallvard> where it means the same as no auth. OTOH, FTP (at least > Hallvard> on Unix) implements anonymous auth the way Sam > Hallvard> describes: A specific user on the server's system, with > Hallvard> limited access. > >> I think my statement is still generally true. It may happen > >> that the authorization ID of anonymous users is also the same > >> as the authorization ID of users who have engaged in no > >> authentication exchange. > > Kurt> But here you are talking about some authorization ID which > Kurt> the service merely associates with the state of being > Kurt> anonymous (having an unknown or concealed identity). > >Agree.d > > Kurt> This > Kurt> is quite different than saying that anonymous users have > Kurt> established (authenticated) THEIR identity in the service. > >I don't see the difference. IN both cases, the identity (or >non-identity) you are authorized as establishes your privileges in the >system. The difference is that, when using ANONYMOUS, users don't establish THEIR identity, they establish some factor in the server which allows them access without requiring that they establish THEIR identity. Sure, a system can associate some identity representation to all users which have not established THEIR identity, but that imply the user has established THEIR identity. And, I would hope, we can agree on whether or not the system does associate some identity representation to all users which not established THEIR identities or not, or what that identity representation might be, is completely beyond the scope of this mechanism. Just as what authorization identity representation the system might associate with an user who DOES establish their identity is beyond the scope of the mechanism. From owner-ietf-sasl Sat Apr 10 13:58:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AKwIvq081233; Sat, 10 Apr 2004 13:58:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AKwI98081232; Sat, 10 Apr 2004 13:58:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-FIFTY-THREE.MIT.EDU [18.187.6.98]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AKwGhv081226 for ; Sat, 10 Apr 2004 13:58:16 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 7218415159C; Sat, 10 Apr 2004 16:58:21 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410103203.04ae46b8@127.0.0.1> <6.0.1.1.0.20040410130528.04b19dd8@127.0.0.1> From: Sam Hartman Date: Sat, 10 Apr 2004 16:58:21 -0400 In-Reply-To: <6.0.1.1.0.20040410130528.04b19dd8@127.0.0.1> (Kurt D. Zeilenga's message of "Sat, 10 Apr 2004 13:25:22 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> This is quite different than saying that anonymous users Kurt> have established (authenticated) THEIR identity in the Kurt> service. >> I don't see the difference. IN both cases, the identity (or >> non-identity) you are authorized as establishes your privileges >> in the system. Kurt> The difference is that, when using ANONYMOUS, users don't Kurt> establish THEIR identity, they establish some factor in the Kurt> server which allows them access without requiring that they Kurt> establish THEIR identity. That sort of depends on your model for identity. It seems completely reasonable to say something along the following lines. Anonymous establishes the anonymous identity with no confidence in that identity. IP address-based authentication establishes an identity based on the IP address with low confidence in that identity. AUthentication by assertion establishes the asserted identity with low confidence in that assertion. External authentication with a client TLS certificate establishes the SubjectName of the certificate as the identity with reasonably high confidence in that identity. Now in this working group we don't really care about the properties of the identity established by anonymous authentication. For example, we don't care if the identities resulting from two different anonymous authentications compare to be equal or are guaranteed to be distinct. You probably want one of the two to be true and for most purposes you don't care which. Again, I think we are arguing about isomorphic models. Conceptually,believe there is an identity and some factor indicating whether the identity has been established. I believe that one class of identity is the unestablished identity. So why am I arguing over isomorphisms? Unfortunately, the particular conceptual model we use seems to appear at least in part in the text of the base specification. I believe that treating everything as authentication will make that base specification easier to understand at the cost of hiding conceptual complexity in anonymous. I may be wrong; this may confuse people to much and be important to change. I'm also arguing to show that this is not an editorial correction to the base specification. You're proposing changing how we think about SASL or at least expanding an area of thought about SASL where our previous thinking was vague. Making that change is a reasonable thing for the working group to do, but it does need to meet a slightly higher bar than an editorialclarification. Kurt> Sure, a system can associate some Kurt> identity representation to all users which have not Kurt> established THEIR identity, but that imply the user has Kurt> established THEIR identity. Kurt> And, I would hope, we can agree on whether or not the system Kurt> does associate some identity representation to all users Kurt> which not established THEIR identities or not, or what that Kurt> identity representation might be, is completely beyond the Kurt> scope of this mechanism. Just as what authorization Kurt> identity representation the system might associate with an Kurt> user who DOES establish their identity is beyond the scope Kurt> of the mechanism. Agreed. From owner-ietf-sasl Sat Apr 10 13:47:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AKlKAh080090; Sat, 10 Apr 2004 13:47:20 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AKlKSi080089; Sat, 10 Apr 2004 13:47:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AKlKEk080083 for ; Sat, 10 Apr 2004 13:47:20 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3AKlOMs036861; Sat, 10 Apr 2004 20:47:24 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040410134518.04ae6468@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 10 Apr 2004 13:47:08 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication [corrected] Cc: Hallvard B Furuseth , ietf-sasl@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I need to slow down... At 11:09 AM 4/10/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> At 09:58 AM 4/10/2004, Sam Hartman wrote: > Hallvard> See above. Also, Sam's statement that all ANONYMOUS > Hallvard> users have the _same_ authorization ID, not _no_ > Hallvard> authorization ID. Which made me realize that anonymous > Hallvard> auth is not a SASL term, but one I'm used to from LDAP, > Hallvard> where it means the same as no auth. OTOH, FTP (at least > Hallvard> on Unix) implements anonymous auth the way Sam > Hallvard> describes: A specific user on the server's system, with > Hallvard> limited access. > >> I think my statement is still generally true. It may happen > >> that the authorization ID of anonymous users is also the same > >> as the authorization ID of users who have engaged in no > >> authentication exchange. > > Kurt> But here you are talking about some authorization ID which > Kurt> the service merely associates with the state of being > Kurt> anonymous (having an unknown or concealed identity). > >Agree.d > > Kurt> This > Kurt> is quite different than saying that anonymous users have > Kurt> established (authenticated) THEIR identity in the service. > >I don't see the difference. IN both cases, the identity (or >non-identity) you are authorized as establishes your privileges in the >system. The difference is that, when using ANONYMOUS, users don't establish THEIR identity, they establish some factor in the server which allows them access without requiring that they establish THEIR identity. Sure, a system can associate some identity representation to all users which have not established THEIR identity, but that DOES NOT imply the user has established THEIR identity. And, I would hope, we can agree on whether or not the system does associate some identity representation to all users which not established THEIR identities or not, or what that identity representation might be, is completely beyond the scope of this mechanism. Just as what authorization identity representation the system might associate with an user who DOES establish their identity is beyond the scope of the mechanism. From owner-ietf-sasl Sat Apr 10 17:49:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3B0nE4q000514; Sat, 10 Apr 2004 17:49:14 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3B0nERJ000513; Sat, 10 Apr 2004 17:49:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3B0nELb000505 for ; Sat, 10 Apr 2004 17:49:14 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3B0nJMs040892; Sun, 11 Apr 2004 00:49:19 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040410145813.0526eb00@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 10 Apr 2004 17:49:02 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410103203.04ae46b8@127.0.0.1> <6.0.1.1.0.20040410130528.04b19dd8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 01:58 PM 4/10/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> This is quite different than saying that anonymous users > Kurt> have established (authenticated) THEIR identity in the > Kurt> service. > >> I don't see the difference. IN both cases, the identity (or > >> non-identity) you are authorized as establishes your privileges > >> in the system. > > Kurt> The difference is that, when using ANONYMOUS, users don't > Kurt> establish THEIR identity, they establish some factor in the > Kurt> server which allows them access without requiring that they > Kurt> establish THEIR identity. >That sort of depends on your model for identity. I think it depends more on who is establishing what, and by what means. When ANONYMOUS is being used, the USER is not required to establish THEIR identity. Whether or not the server-side mechanism implementation represents, or how it represents, to the server-side protocol implementation that the USER has requested access be granted on an anonymous-basis (e.g, with requiring the USER to establish THEIR identity), as well as how that server-side protocol implementation might then use this information in authorization decisions is a separate (and separable) issue. >It seems completely reasonable to say something along the following >lines. Anonymous establishes the anonymous identity with no >confidence in that identity. IP address-based authentication >establishes an identity based on the IP address with low confidence in >that identity. AUthentication by assertion establishes the asserted >identity with low confidence in that assertion. External >authentication with a client TLS certificate establishes the >SubjectName of the certificate as the identity with reasonably high >confidence in that identity. In the three non-anonymous examples you provide, each requires the user to disclose its identity. In the anonymous case, the user is not required to disclose information its identity (though the user might be identifiable otherwise). So, I think, your analogy is a bit flawed. But, what concerns me is implication that the ANONYMOUS mechanism establishes through the exchange an identity representation that refers users who have not established their entity. I find that implication misleading and confusing. If such a representation is to be established, it's being established by, for, and within server implementation. That is, such is being manufactured outside of the mechanism exchange as defined by this specification. >Now in this working group we don't really care about the properties of >the identity established by anonymous authentication. For example, we >don't care if the identities resulting from two different anonymous >authentications compare to be equal or are guaranteed to be distinct. I agree. >Again, I think we are arguing about isomorphic models. >Conceptually,believe there is an identity and some factor indicating >whether the identity has been established. I believe that one class >of identity is the unestablished identity. > >So why am I arguing over isomorphisms? I think we're arguing over whether "to authenticate" means "to verify" or whether it means "to login (with our without verification)". SASL mechanisms are login mechanisms: some provide authenticated login capabilities, some provide anonymous login capabilities. >Unfortunately, the particular >conceptual model we use seems to appear at least in part in the text >of the base specification. I think the base specification has problems in three areas (that impact this discussion): 1) The base specification does not use terms consistently, 2) The base specification doesn't always define the terms it uses, and 3) The base specification is not clear that as to the range of function that a SASL mechanism can provide. >I believe that treating everything as >authentication will make that base specification easier to understand >at the cost of hiding conceptual complexity in anonymous. To a certain degree I agree that some of the conceptual complexity can be hidden in ANONYMOUS, excepting the base specification needs to be clear that not everything fits the easier to understand model which the base specification puts forth. Anyways, in regards to the ANONYMOUS specification, I'm going to offer a slightly revised intro text for the WG to consider here shortly. However, I think the base specification needs work to be more easily understood. For instance, 2222bis uses of the terms: SASL authentication mechanism, SASL mechanism, authentication mechanism, and mechanism generally in an interchangeable fashion. However, in some uses in the document where it obvious that they are not interchangeable. This confuses all the uses which the author used them interchangeable, leaving a mess for the reader to decipher. I think it would be far better if we would consistently use the term "SASL mechanism" (and "mechanism" only where it is clear we're referring to a SASL mechanism) as RFC 2222 generally did. And I think we should be more clear as to what functions SASL mechanisms generally provide (and how some may offer vastly different functions than other mechanisms). >I may be wrong; this may confuse people to much and be important to change. At the moment, some readers of 2222bis are going to be confused as some of the terminology is new and different than what was used in RFC 2222, BUT the largest problem is that much of the terminology (new and old) is not well-defined and/or not used consistently. >I'm also arguing to show that this is not an editorial correction to >the base specification. You're proposing changing how we think about >SASL or at least expanding an area of thought about SASL where our >previous thinking was vague. I don't think I am arguing that we change how we think about SASL. I am mostly arguing that we clean up our terminology. And I am objecting to use of language which is not consistent with our terminology. Of course, "what is our terminology" is a bit of an open question given that 2222bis does well-define our terminology. >Making that change is a reasonable thing >for the working group to do, but it does need to meet a slightly >higher bar than an editorialclarification. Inconsistent use of poorly-defined terminology is, I think, not just an "editorial clarification" concern, it's a general technical quality concern. Kurt From owner-ietf-sasl Sun Apr 11 11:33:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BIXskd081887; Sun, 11 Apr 2004 11:33:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3BIXsM8081886; Sun, 11 Apr 2004 11:33:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BIXqjQ081860 for ; Sun, 11 Apr 2004 11:33:53 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1BCjmA-0001tf-SQ; Sun, 11 Apr 2004 20:33:50 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.30) id 1BCjm6-0007L6-LP; Sun, 11 Apr 2004 20:33:46 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BCjm5-0006MU-00; Sun, 11 Apr 2004 20:33:45 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Sam Hartman , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication In-Reply-To: <6.0.1.1.0.20040410110652.04af8cf8@127.0.0.1> References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> <6.0.1.1.0.20040410110652.04af8cf8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sun, 11 Apr 2004 20:33:45 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >At 10:33 AM 4/10/2004, Hallvard B Furuseth wrote: >>Kurt D. Zeilenga writes: >>>At 07:53 AM 4/10/2004, Hallvard B Furuseth wrote: >>>>Kurt D. Zeilenga writes: >>>>> The anonymous mechanism doesn't provide any >>>>> authentication service. (Not all SASL mechanisms provide >>>>> authentication services.) >>>> >>>> That's not what rfc2222bis says. It describes SASL mechanisms as >>>> authentication mechanisms, and describes everything about these in >>>> terms of authentication. >>> >>> Which is a problem. rfc2222bis should be likely use more >>> generic terms, like "SASL mechanism" when referring to a >>> SASL mechanism. >> >> rfc2222 does the same thing. > > RFC 2222 only once used the term "authentication mechanism". > This was in the security consideration section, Sorry, I should have said I looked for 'authentication' and 'authorization' in general. In particular the term 'authentication protocol exchange' is recurring. E.g.: 3. Introduction and Overview The Simple Authentication and Security Layer (SASL) is a method for adding authentication support to connection-based protocols. (...) If a server supports the requested mechanism, it initiates an authentication protocol exchange. (...) During the authentication protocol exchange, the mechanism performs authentication, transmits an authorization identity (...) 5.3. Multiple authentications 4. Profiling requirements 5. A specification of how the authorization identity passed from the client to the server is to be interpreted. [ANONYMOUS] does not fulfill that requirement. >> Did it incorrectly describe existing >> implementations, or were mechanisms like ANONYMOUS added later? > > Often one describes features of protocols based upon what > purpose they generally serve even though they might not > always be used for that purpose. See say "security layer" > even though the feature (say data compression) may not used > to provide non-security layer . > > The fact that we name these features as we do, it should be > made clear that they do not always provide the function the > names imply. This should be made clear in RFC 2222. True. (I approached this whole thing from the point of view of a user of a SASL library, who knows SASL but may not be aware that there are mechanisms that do not provide what the SASL spec might make one assume it provides.) >> Correction: It needs to say which authentication and authorization IDs >> it _requests_. Or provides, or whatever is the correct term. Hopefully >> these IDs will be treated just like IDs from other SASL mechanisms. >> Or like no ID (unauthenticated), if that's what the mechanism requests. > > ANONYMOUS doesn't request nor provide an authentication ID nor an > authorization ID. There has to be _some_ way to say that ANONYMOUS changes the authentication ID, or requests a change of it, or however you wish to say that, and what that new ID is, or that the new ID is absent, or however you wish to say that. Could you please provide a wording for that which you will accept, so we can at least talk about how it relates to the authentication ID? Maybe just some wording to satisfy the SASL 'Profiling requirements' requirement above. I'll hold off replying to part of your message (if a reply to the rest still seems relevant) until then. > Note that there could be other mechanisms would also do not > provide such IDs to the server. See the section from '4. Profiling requirements' quoted above. > Consider a mechanism which > only authenticated the server to the client. Hmm - I suppose the mechanism could specify that the authentication ID is the one which was already in use. > Anyways, I think it sufficient for the mechanism to say what it > provides (no IDs in the case of ANONYMOUS). How that's used > in application protocol (or implementations thereof) is simply > beyond the scope of the mechanism specification. Yes. >>> It should be obvious that this mechanism does not itself >>> establish an authentication identity nor transfer an authorization >>> identity. However, if more clarity is needed, I would suggest >>> replacing the paragraph: >>> This mechanism does not provide a security layer. >>> with: >>> This mechanism does not establish the identity of the >>> client (or user) nor the server (or service); does not >>> support transfer of an authorization identity; nor >>> provide a security layer. >> >> I think either 'It requests anonymous authentication and authorization >> identities. > > I assume It == user here. I meant it = mechanism. Though it's on behalf of the user, if that's what you mean. > I'm describing what the mechanism > establishes and not (in this paragraph) what the user may or > may not request using this mechanism. But 'establishes' is wrong - as you said, how any mechanism affects authentication and authorization IDs outside of the mechanism is beyond the scope of that mechanism. >> How to treat the anonymous ID is up to the protocol or >> implementation.', or 'It does not affect the authentication and >> authorization identities'. > > The latter is especially dangerous Well, I hoped that was not what it does. Your recent messages in this thread just made me wonder if it did. >>>> Also, I now wonder how clients typically implement ANONYMOUS. If they >>>> support several SASL mechanisms, do clients expect the identity to send >>>> with ANONYMOUS in the same command line option or whatever which they >>>> use for the authentication IDs for other SASL mechanisms, or do they use >>>> some other field? >>> >>> I suggest you look at some existing implementations. >> >> I don't know where to find any... > > Cyrus SASL? Yes. But a client and a server which uses the mechanism? Anyway, I kind of hoped someone who already use SASL could tell me, so I won't have to compile and install stuff just to find out. The only example I know of is openldap ldapsearch. It does not treat auth(c/z) ID as trace ID. >>> But >>> I would hope the user would not be asked or expected to >>> provide their credentials (or portions of their credentials) >>> when using this mechanism. >> >> If you mean e.g. a password, I agree. > > I mean credentials. Credentials may include many things... > and generally (but not necessarily) includes a representation of > the identity they are used to establish. For instance, in > PLAIN, the credentials include both a representation of > the user's identity and a password. The user has to know > both to gain access as that user. OK. >> However, I was thinking of >> clients that authenticate to the server > > Who are they authenticating? Themselves or whatever entity is > using the client? SASL general function is to authenticate > the client (or entity which is using a client) to the server. Sure. > It's not to authenticate the entity using the client to the > client. > > This is not to say that clients cannot do that, but the > security considerations for using SASL in this fashion are > broad and wide. Perhaps they should be discussed in rfc2222bis? >> and then grant access to >> something on the client side depending on whether or not authentication >> succeeds. > > Such a client would need to treat ANONYMOUS as not establishing > the user's entity. Here, at least, the client can just disallow > the mechanism. A client which uses PLAIN, CRAM-MD5, etc., for > such has it far worse. They need to know which user names > have widely known passwords or user names are granted access > regardless of what password is provided. How many PLAIN > deployments out there accept any password for "anonymous"? Do you mean such things come with the default SASL setup with some implementations? That sounds scary enough that it might be an idea to warn about it in rfc2222bis. Otherwise I don't see the problem. The client will authenticate against a server which it knows is set up to authenticate the possible users of that clients. Other user names will not be recognized. Except ANONYMOUS "user names", if the client treats the trace information sent with ANONYMOUS the same way it treats user names for other mechanisms. Anyway, I simply wondered if clients do that. I hope not. >> Or it could refuse the user to specify the ANONYMOUS >> mechanism, of course. > > If a client is going to use mechanisms to authorize users > to access services AT the client, then it needs to understand > not only the services provided by the mechanism, but > protocol/implementation/deployment details of the server > it using in support of user authentication to the client. OK. >>> But it should be clear that anonymous methods in LDAP, FTP, >>> and elsewhere are not authenticating the user's identity. >> >> In LDAP it does not authenticate. In FTP it does, to the server. The >> anonymous user has the access which the filesystem grants to a specific >> user on the filesystem. > > The problem with your statement, in my opinion, is the > implication that the user's identity seeking anonymous > access has THEIR identity authenticated. (...) I don't think so. Users of shared accounts don't authenticate as THEIR identities either. My nearest public library has the public account's username and password taped to the public computers, so people can reboot the beasts without running to a librarian for help. That's not the user's identity either. All that any SASL mechanism authenticates is that the client provided sufficient credentials to authenticate in the manner it did. Which is none at all, in the ANONYMOUS case. The administrator who allowed that authentication is the one who knows what it means that someone authenticated that way, and what access to grant. -- Hallvard From owner-ietf-sasl Sun Apr 11 11:41:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BIf5H1083134; Sun, 11 Apr 2004 11:41:05 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3BIf55C083133; Sun, 11 Apr 2004 11:41:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BIf4nt083118 for ; Sun, 11 Apr 2004 11:41:05 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1BCjt9-00035M-GK; Sun, 11 Apr 2004 20:41:03 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.30) id 1BCjt3-00085A-11; Sun, 11 Apr 2004 20:40:57 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BCjt2-0006Mp-00; Sun, 11 Apr 2004 20:40:56 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Sam Hartman , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> <6.0.1.1.0.20040410110652.04af8cf8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sun, 11 Apr 2004 20:40:56 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Grumble. Read through a message two times before sending, then discover a mistake just after sending:-( I wrote: > 4. Profiling requirements > 5. A specification of how the authorization identity passed from the > client to the server is to be interpreted. > > [ANONYMOUS] does not fulfill that requirement. I meant, [ANONYMOUS] as currently described, or as you describe it, does not provide such an authorization identity for the protocol to interpret. Even if it is not 'passed from the client', the protocol spec needs to get an authorization identity from the SASL mechanism in order to fulfill this requirement. -- Hallvard From owner-ietf-sasl Sun Apr 11 11:54:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BIsf8B084826; Sun, 11 Apr 2004 11:54:41 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3BIsfR3084824; Sun, 11 Apr 2004 11:54:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BIseVW084811 for ; Sun, 11 Apr 2004 11:54:40 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1BCk6L-0005QB-64 for ietf-sasl@imc.org; Sun, 11 Apr 2004 20:54:41 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.30) id 1BCk6I-0000sg-6j; Sun, 11 Apr 2004 20:54:38 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BCk6H-0006PO-00; Sun, 11 Apr 2004 20:54:37 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis: authentication identity Date: Sun, 11 Apr 2004 20:54:37 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: rfc2222bis has added the concept of an authentication identity since rfc2222. Is this identity only a parameter to the SASL authentication process, and can be discarded after SASL authentication is complete? Or is it also part of the connecton's authorization state after SASL authentication? If so, what for? Could you clarify that in the draft? -- Hallvard From owner-ietf-sasl Sun Apr 11 14:00:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BL0QmD003224; Sun, 11 Apr 2004 14:00:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3BL0QOO003223; Sun, 11 Apr 2004 14:00:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BL0P9d003217 for ; Sun, 11 Apr 2004 14:00:25 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3BL0UMs055396; Sun, 11 Apr 2004 21:00:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040411121900.04ad5490@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sun, 11 Apr 2004 14:00:12 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication Cc: Sam Hartman , ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> <6.0.1.1.0.20040410110652.04af8cf8@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: As I noted in my response, we use often use the terms based on "to authenticate" to mean "to login" instead of "to verify". I think the "A"authentication in SASL is commonly used in the "to login" fashion. rfc2222bis needs to be more clear here, as it is dangerous to say things are "authenticated" when they are not "verified". And, I think, we should avoid using terms such as "authentication mechanism" when there are reasonable alternatives (such as "SASL mechanism"). At 11:33 AM 4/11/2004, Hallvard B Furuseth wrote: >(I approached this whole thing from the point of view of a user >of a SASL library, who knows SASL but may not be aware that there are >mechanisms that do not provide what the SASL spec might make one assume >it provides.) The SASL specification should be more clear that not all mechanisms verify (or even establish) the user's identity, not all mechanisms pass authorization identity information, not all mechanism support security layers, etc.. That is, the range of function that mechanisms offer can vary widely. And, I think, it very important that to be clear that SASL does not abstract away the differences between mechanisms. Something in the client/server protocol implementation needs to deal with them. Maybe the implementation uses a SASL library that abstracts away some of these differences, but it should be clear something at both the client and the server has to deal with the differences. SASL framework doesn't hide mechanism particulars from protocols. >>> Correction: It needs to say which authentication and authorization IDs >>> it _requests_. Or provides, or whatever is the correct term. Hopefully >>> these IDs will be treated just like IDs from other SASL mechanisms. >>> Or like no ID (unauthenticated), if that's what the mechanism requests. >> >> ANONYMOUS doesn't request nor provide an authentication ID nor an >> authorization ID. > >There has to be _some_ way to say that ANONYMOUS changes the >authentication ID, or requests a change of it, or however you wish to >say that, and what that new ID is, or that the new ID is absent, or >however you wish to say that. By use of the ANONYMOUS mechanism, the client communicates to the server that the user wishes to access the services/resources provided by server on an anonymous basis (e.g., without disclosing its identity to the server). If the server is willing and able, it responds accordingly to the request and takes appropriate actions within its authorization system to grant that access. Note here the separation between what information is communicated by the mechanism and what the server implementation does with that information. Details of how identity information (including lack of knowing the user's identity) is represented by the server are outside the scope of the mechanism specification. >Could you please provide a wording for >that which you will accept, so we can at least talk about how it relates >to the authentication ID? In respect to the mechanism, no authentication ID is communicated. How a server implementation represents that no authentication ID was communicated by the mechanism is its business. >Maybe just some wording to satisfy the SASL >'Profiling requirements' requirement above. Above you called this profiling requirement: A specification of how the authorization identity passed from the client to the server is to be interpreted. This requirement means that protocol (not mechanism) specifications are to define the form used to representation the proxy authorization identity. It should not be viewed as requiring all mechanisms to actually pass a proxy authorization identity information from client-to-server. >> Anyways, I think it sufficient for the mechanism to say what it >> provides (no IDs in the case of ANONYMOUS). How that's used >> in application protocol (or implementations thereof) is simply >> beyond the scope of the mechanism specification. > >Yes. Noted. >>>> It should be obvious that this mechanism does not itself >>>> establish an authentication identity nor transfer an authorization >>>> identity. However, if more clarity is needed, I would suggest >>>> replacing the paragraph: >>>> This mechanism does not provide a security layer. >>>> with: >>>> This mechanism does not establish the identity of the >>>> client (or user) nor the server (or service); does not >>>> support transfer of an authorization identity; nor >>>> provide a security layer. >>> >>> I think either 'It requests anonymous authentication and authorization >>> identities. >> >> I assume It == user here. > >I meant it = mechanism. Though it's on behalf of the user, if that's >what you mean. > >> I'm describing what the mechanism >> establishes and not (in this paragraph) what the user may or >> may not request using this mechanism. > >But 'establishes' is wrong - as you said, how any mechanism affects >authentication and authorization IDs outside of the mechanism is beyond >the scope of that mechanism. I think you are not seeing the separation between what information a mechanism may or may not provide to the client/server, and how that information might be used by the client/server. In the above text, I was referring to what information the mechanism provides to the client/server as opposed to affects which are outside the mechanism. >> Cyrus SASL? > >Yes. But a client and a server which uses the mechanism? I believe you can configure OpenLDAP to make use of the mechanism. Likely Cyrus SASL's own sample client/server may use this mechanism. >Anyway, I kind of hoped someone who already use SASL could tell me, >so I won't have to compile and install stuff just to find out. It's no different than supporting any other mechanism. You need to understand what information the mechanism provide, its semantics, and then map that information into your authorization system. SASL itself doesn't abstract away mechanism differences (but your SASL library might). >The only example I know of is openldap ldapsearch. It does not >treat auth(c/z) ID as trace ID. GOOD. >> It's not to authenticate the entity using the client to the >> client. >> >> This is not to say that clients cannot do that, but the >> security considerations for using SASL in this fashion are >> broad and wide. > >Perhaps they should be discussed in rfc2222bis? Like, in my best Elmer Fudd voice, "be very, very careful" :-) >>> and then grant access to >>> something on the client side depending on whether or not authentication >>> succeeds. >> >> Such a client would need to treat ANONYMOUS as not establishing >> the user's entity. Here, at least, the client can just disallow >> the mechanism. A client which uses PLAIN, CRAM-MD5, etc., for >> such has it far worse. They need to know which user names >> have widely known passwords or user names are granted access >> regardless of what password is provided. How many PLAIN >> deployments out there accept any password for "anonymous"? > >Do you mean such things come with the default SASL setup with some >implementations? That sounds scary enough that it might be an idea to >warn about it in rfc2222bis. I think we need a brief warning. SASL purpose is to "login" the client to the server. It's not designed "login" the user to the client. What the server might find acceptable, may not be acceptable to the client. >Client's using SASL for the purposes of granting access to services/resources >at the client should be "very, very careful" not to make invalid assumptions >about the success (or failure) of a SASL mechanism exchange. >All that any SASL mechanism authenticates is that the client provided >sufficient credentials to authenticate in the manner it did. Which is >none at all, in the ANONYMOUS case. The administrator who allowed >that authentication is the one who knows what it means that someone >authenticated that way, and what access to grant. Noting that you are using the "to authenticate" (and variants) to mean "to login", I would have to agree with this statement. In particular, I agree that client does not provide any credentials when using the ANONYMOUS mechanism. This has been one of my points through this discussion. Kurt From owner-ietf-sasl Sun Apr 11 19:49:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3C2nQ6Y045832; Sun, 11 Apr 2004 19:49:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3C2nQns045831; Sun, 11 Apr 2004 19:49:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3C2nPAh045822 for ; Sun, 11 Apr 2004 19:49:25 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3C2nWMs060390 for ; Mon, 12 Apr 2004 02:49:32 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040411194237.0491d150@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sun, 11 Apr 2004 19:49:14 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: clarification as to the purpose of ANONYMOUS mechanism 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: In response to recent discussions on this list, I propose to insert the following paragraph between the existing first and second paragraphs of Section 1 of draft-ietf-sasl-anon-xx.txt: Unlike many other SASL mechanisms whose purpose is to authenticate and identify the user to a server, the purpose of this SASL mechanism is to allow the user to gain access to services or resources without requiring the user to establish or otherwise disclose their identity to the server. That is, this mechanism provides an anonymous login method. Comments? Kurt From owner-ietf-sasl Mon Apr 12 09:03:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CG3vCa014178; Mon, 12 Apr 2004 09:03:57 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CG3vhG014177; Mon, 12 Apr 2004 09:03:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-FIFTY-THREE.MIT.EDU [18.187.6.98]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CG3uuF014170 for ; Mon, 12 Apr 2004 09:03:56 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 6CDF715159C; Mon, 12 Apr 2004 12:03:59 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> <6.0.1.1.0.20040410110652.04af8cf8@127.0.0.1> <6.0.1.1.0.20040411121900.04ad5490@127.0.0.1> From: Sam Hartman Date: Mon, 12 Apr 2004 12:03:59 -0400 In-Reply-To: <6.0.1.1.0.20040411121900.04ad5490@127.0.0.1> (Kurt D. Zeilenga's message of "Sun, 11 Apr 2004 14:00:12 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> As I noted in my response, we use often use the terms based Kurt> on "to authenticate" to mean "to login" instead of "to Kurt> verify". I think the "A"authentication in SASL is commonly Kurt> used in the "to login" fashion. Kurt> rfc2222bis needs to be more clear here, as it is dangerous Kurt> to say things are "authenticated" when they are not Kurt> "verified". With my security hat on, I have to disagree. Not verified at all is just one point along the continuum of verification. The security difference between not verified and poorly verified is not particularly significant. I'm going to try and say less on this issue as making a consensus call is already going to be challenging. From owner-ietf-sasl Mon Apr 12 10:44:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CHiPjr025026; Mon, 12 Apr 2004 10:44:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CHiPhM025025; Mon, 12 Apr 2004 10:44:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CHiORO025016 for ; Mon, 12 Apr 2004 10:44:24 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3CHiSMs073045; Mon, 12 Apr 2004 17:44:28 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040412093816.04a302e8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 12 Apr 2004 10:44:09 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> <6.0.1.1.0.20040410110652.04af8cf8@127.0.0.1> <6.0.1.1.0.20040411121900.04ad5490@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:03 AM 4/12/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> As I noted in my response, we use often use the terms based > Kurt> on "to authenticate" to mean "to login" instead of "to > Kurt> verify". I think the "A"authentication in SASL is commonly > Kurt> used in the "to login" fashion. I like to replace "to login" in the above comment with "to identify". I don't may describing ANONYMOUS mechanism as identifying the user as an anonymous user. I have a problem saying the that the ANONYMOUS verifies the user's identity is anonymous. The latter gives off a number of false impressions. It particular, the latter can be read as implying the ANONYMOUS mechanism is providing verified user identity privacy. > Kurt> rfc2222bis needs to be more clear here, as it is dangerous > Kurt> to say things are "authenticated" when they are not > Kurt> "verified". > >With my security hat on, I have to disagree. Not verified at all is >just one point along the continuum of verification. The security >difference between not verified and poorly verified is not >particularly significant. I agree to your statement as it applies to verification. I would also agree that there is wide continuum of identification. However, I disagree that the terms verification and identification are synonymous. Whether any harm can be caused to inappropriate interchange depends on the particular case. My particular gripe with rfc2222bis is not defining well its terminology and it not terrible self consistent with its use of that terminology. Kurt From owner-ietf-sasl Mon Apr 12 11:37:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CIbDaX031121; Mon, 12 Apr 2004 11:37:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CIbDE7031120; Mon, 12 Apr 2004 11:37:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CIbC1Y031111 for ; Mon, 12 Apr 2004 11:37:13 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 8C43215159C; Mon, 12 Apr 2004 14:37:16 -0400 (EDT) To: ietf-sasl@imc.org Subject: Proposed text for adaptive plaintext attacks Message-Id: <20040412183716.8C43215159C@konishi-polis.mit.edu> Date: Mon, 12 Apr 2004 14:37:16 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I propose to replace the following text in section 9: Distributed server implementations need to be careful in how they trust other parties and, in particular, authentication secrets should only be disclosed to other parties that are trusted to manage and use those secrets in manner acceptable to disclosing party. It should be noted that, where those secrets are used to provide data confidentiality protections, if a third party (other than the discloser/disclosee) has knowledge of some portion of the protected information, it can use this knowledge in an attack upon other portions of the protected information. <
> with the following text: Distributed server implementations need to be careful in how they trust other parties and, in particular, authentication secrets should only be disclosed to other parties that are trusted to manage and use those secrets in manner acceptable to disclosing party. Applications using SASL assume that SASL security layers providing confidentiality are secure even when an attacker chooses the text to be protected by the security layer. Similarly applications assume that the SASL security layer is secure even if the attacker can manipulate the ciphertext output of the security layer. With the exception of the DES modes of the digest-md5 mechanism, all SASL mechanisms standardized by the IETF are believed to meet these security assumptions. New SASL mechanisms MUST meet these assumptions. Do people feel that explicit text about security considerations of CBC belong in the base SASL specification? --Sam From owner-ietf-sasl Mon Apr 12 12:32:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CJWSiV037912; Mon, 12 Apr 2004 12:32:28 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CJWSS8037911; Mon, 12 Apr 2004 12:32:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CJWQVj037905 for ; Mon, 12 Apr 2004 12:32:27 -0700 (PDT) (envelope-from rbunch@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 PAA08768; Mon, 12 Apr 2004 15:32:28 -0400 (EDT) Message-Id: <200404121932.PAA08768@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-saslprep-08.txt Date: Mon, 12 Apr 2004 15:32:28 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : SASLprep: Stringprep profile for user names and passwords Author(s) : K. Zeilenga Filename : draft-ietf-sasl-saslprep-08.txt Pages : 6 Date : 2004-4-12 This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the 'SASLprep' profile of the 'stringprep' algorithm to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging simple user names and/or passwords. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-saslprep-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-saslprep-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-12154057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-saslprep-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-saslprep-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-12154057.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Mon Apr 12 13:14:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CKE4aW044063; Mon, 12 Apr 2004 13:14:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CKE4sr044062; Mon, 12 Apr 2004 13:14:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CKE4Qu044056 for ; Mon, 12 Apr 2004 13:14:04 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3CKE8Ms075828 for ; Mon, 12 Apr 2004 20:14:08 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040412130620.04a88b98@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 12 Apr 2004 13:13:49 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-saslprep-08.txt In-Reply-To: <200404121932.PAA08768@ietf.org> References: <200404121932.PAA08768@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: FYI, this revision addresses two issues raised during IETF Last Call. 1) The StringPrep references now points to RFC 3454. This to keep SASLprep from blocking on the StringPrep I-D. 2) The SASL reference was reclassified as Informative as the reader need not read nor understand SASL reference material to implement or make use of SASLprep. Kurt At 12:32 PM 4/12/2004, 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 : SASLprep: Stringprep profile for user names and passwords > Author(s) : K. Zeilenga > Filename : draft-ietf-sasl-saslprep-08.txt > Pages : 6 > Date : 2004-4-12 > >This document describes how to prepare Unicode strings representing > user names and passwords for comparison. The document defines the > 'SASLprep' profile of the 'stringprep' algorithm to be used for both > user names and passwords. This profile is intended to be used by > Simple Authentication and Security Layer (SASL) mechanisms (such as > PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging > simple user names and/or passwords. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-08.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-sasl-saslprep-08.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-sasl-saslprep-08.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-4-12154057.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-sasl-saslprep-08.txt > > From owner-ietf-sasl Tue Apr 13 03:53:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DAr5KK030389; Tue, 13 Apr 2004 03:53:05 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3DAr527030388; Tue, 13 Apr 2004 03:53:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DAr4Ce030369 for ; Tue, 13 Apr 2004 03:53:04 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 13 Apr 2004 11:53:01 +0100 Message-ID: <407BC68A.5070800@isode.com> Date: Tue, 13 Apr 2004 11:52:58 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Proposed text for adaptive plaintext attacks References: <20040412183716.8C43215159C@konishi-polis.mit.edu> In-Reply-To: <20040412183716.8C43215159C@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: >I propose to replace the following text in section 9: > > Distributed server implementations need to be careful in how they > trust other parties and, in particular, authentication secrets should > only be disclosed to other parties that are trusted to manage and use > those secrets in manner acceptable to disclosing party. It should be > noted that, where those secrets are used to provide data > confidentiality protections, if a third party (other than the > discloser/disclosee) has knowledge of some portion of the protected > information, it can use this knowledge in an attack upon other > portions of the protected information. > > <
on a distributed server implementation. The section also gives some > recommendations about mitigating such attacks.>> > >with the following text: > > Distributed server implementations need to be careful in how they > trust other parties and, in particular, authentication secrets should > only be disclosed to other parties that are trusted to manage and use > those secrets in manner acceptable to disclosing party. > > Applications using SASL assume that SASL security layers providing > confidentiality are secure even when an attacker chooses the text to > be protected by the security layer. Similarly applications assume > that the SASL security layer is secure even if the attacker can > manipulate the ciphertext output of the security layer. With the > exception of the DES modes of the digest-md5 mechanism, all SASL > mechanisms standardized by the IETF are believed to meet these > security assumptions. New SASL mechanisms MUST meet these assumptions. > > > > >Do people feel that explicit text about security considerations of CBC >belong in the base SASL specification? > I personally don't think that the reference to DIGEST-MD5 belongs here. This is better be addressed in DIGEST-MD5. Alexey From owner-ietf-sasl Tue Apr 13 08:51:36 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DFpaTX051741; Tue, 13 Apr 2004 08:51:36 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3DFpa9M051740; Tue, 13 Apr 2004 08:51:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-SIXTY-EIGHT.MIT.EDU [18.187.6.113]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DFpa9K051732 for ; Tue, 13 Apr 2004 08:51:36 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id E189A15159C; Tue, 13 Apr 2004 11:51:38 -0400 (EDT) To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Proposed text for adaptive plaintext attacks References: <20040412183716.8C43215159C@konishi-polis.mit.edu> <407BC68A.5070800@isode.com> From: Sam Hartman Date: Tue, 13 Apr 2004 11:51:38 -0400 In-Reply-To: <407BC68A.5070800@isode.com> (Alexey Melnikov's message of "Tue, 13 Apr 2004 11:52:58 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> I personally don't think that the reference to DIGEST-MD5 Alexey> belongs here. This is better be addressed in DIGEST-MD5. I'm OK with dropping it although I'll explain why I put it there. I believe it is important to characterize how valid a security assumption is. In reviewing the security of SASL, I'd like to know both what the security assumptions are and whether these assumptions are actually reasonable. From owner-ietf-sasl Wed Apr 21 01:25:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3L8PIiH030169; Wed, 21 Apr 2004 01:25:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3L8PIbj030167; Wed, 21 Apr 2004 01:25:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from bisrv2.bysoft-international.fr (host.68.118.23.62.rev.coltfrance.com [62.23.118.68]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3L8PGHe030128 for ; Wed, 21 Apr 2004 01:25:17 -0700 (PDT) (envelope-from cyril.drouin@bysoft.fr) Received: from CYRILBYSOFT ([192.168.2.200]) by bisrv2.bysoft-international.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JLK6LC2A; Wed, 21 Apr 2004 10:25:51 +0200 From: "Cyril Drouin - Bysoft" To: Subject: Issue with SASL/Postfix/MySQL - Nightmare for 3 DAYS :-( Date: Wed, 21 Apr 2004 10:25:12 +0200 Message-ID: <007e01c4277a$2a7dd700$c802a8c0@CyrilBysoft> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007F_01C4278A.EE06A700" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal 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_007F_01C4278A.EE06A700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have tried for 3 days now to integrate SASL/PostFix/MySQL but I can't = make it. =20 What I have done : =20 - Compile Postfix with the SALS and MySQL support : =20 make -f Makefile.init makefiles 'CCARGS=3D-DHAS_MYSQL -I/home/cyril/mysql/include -DUSE_SASL_AUTH -I/usr/local/include/sasl'=20 'AUXLIBS=3D-L/home/cyril/mysql/lib -lmysqlclient -lz -lm -L/usr/local/lib/sasl2 -lsasl2' - Compile SALS with the MySQL support : =20 env CPPFLAGS=3D"-I/usr/include/mysql" LDFLAGS=3D"-L/usr/lib/mysql -R/usr/lib/mysql" ./configure --enable-sql --with-mysql=3D/usr/lib/mysql - Create the smtpd.conf: =20 sasl_pwcheck_method: auxprop sasl_auxprop_plugin: mysql mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM mysql_user: postfix mysql_passwd: password mysql_hostnames: localhost mysql_database: users mysql_statement: SELECT crypt FROM users WHERE address =3D '%u' mysql_verbose: yes - Change my main.cf to : =20 #Authentification SASL =20 smtpd_sasl_auth_enable =3D yes smtpd_sasl2_auth_enable =3D yes broken_sasl_auth_clients =3D yes smtpd_sasl_local_domain =3D smtpd_sasl_security_options =3D noanonymous smtpd_recipient_restrictions =3D permit_sasl_authenticated, = permit_mynetworks, reject_unauth_destination What I am sure of is : - MySQL and POSTFIX integration is working as I can check the email = through pop3/imap (I am using courier-imap package) - Postfix can send message out =20 Few questions : =20 1/ When I compile sasl, I got an error saying that : =20 checking for mysql_select_db in -lmysqlclient... (cached) no configure: WARNING: MySQL library mysqlclient does not work =20 I can't figure out why I got this warning. I used the same library than = for Mysql 2/ I got nothing in maillog. how can I know if SASL is using Mysql ? = even how can I know if Postfix is using SASL ? =20 Few more details : 1/ Redhat 9 2/ Postfix version 2.0.19 =20 3/ SASL SASL2 2.1.18=20 4/ My password are encrypted in my Database=20 =20 Thanks for your answers..I am getting crazy down here with that. =20 Cyril =20 ------=_NextPart_000_007F_01C4278A.EE06A700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
I have = tried for 3=20 days now to integrate SASL/PostFix/MySQL but I can't make=20 it.
 
What I = have done=20 :
 
- = Compile Postfix=20 with the SALS and MySQL support :
 
make = -f=20 Makefile.init makefiles 'CCARGS=3D-DHAS_MYSQL = -I/home/cyril/mysql/include=20 -DUSE_SASL_AUTH -I/usr/local/include/sasl'
 'AUXLIBS=3D-L/home/cyril/mysql/lib -lmysqlclient -lz -lm=20 -L/usr/local/lib/sasl2 -lsasl2'
- = Compile SALS with=20 the MySQL support :
 
env=20 CPPFLAGS=3D"-I/usr/include/mysql" LDFLAGS=3D"-L/usr/lib/mysql=20 -R/usr/lib/mysql"
./configure --enable-sql=20 --with-mysql=3D/usr/lib/mysql
- = Create the=20 smtpd.conf:
 
sasl_pwcheck_method:=20 auxprop
sasl_auxprop_plugin: mysql
mech_list: PLAIN LOGIN CRAM-MD5 = DIGEST-MD5 NTLM
mysql_user: postfix
mysql_passwd:=20 password
mysql_hostnames:=20 localhost
mysql_database: users
mysql_statement: SELECT crypt FROM = users=20 WHERE address =3D '%u'
mysql_verbose: yes
- = Change my=20 main.cf  to :
 
#Authentification=20 SASL
 
smtpd_sasl_auth_enable =3D yes
smtpd_sasl2_auth_enable =3D=20 yes
broken_sasl_auth_clients =3D yes
smtpd_sasl_local_domain=20 =3D
smtpd_sasl_security_options =3D = noanonymous
smtpd_recipient_restrictions =3D=20 permit_sasl_authenticated, permit_mynetworks,=20 reject_unauth_destination
What I = am sure of is=20 :
- = MySQL and POSTFIX=20 integration is working as I can check the email through pop3/imap (I am = using=20 courier-imap package)
- = Postfix can send=20 message out
 
Few = questions=20 :
 
1/ When I=20 compile sasl, I got an error saying that :
 
checking for=20 mysql_select_db in -lmysqlclient... (cached) no
configure: WARNING: = MySQL=20 library mysqlclient does not work
 
I = can't figure out=20 why I got this warning. I used the same library than for Mysql
2/ I = got nothing in=20 maillog. how can I know if SASL is using Mysql ? even how can I know if = Postfix=20 is using SASL ?
 
Few = more details=20 :
1/ = Redhat=20 9
2/ Postfix=20 version 2.0.19  
3/ SASL SASL2=20 2.1.18 
4/ My password are = encrypted=20 in my Database 
 
Thanks = for your=20 answers..I am getting crazy down here with that.
 
Cyril
 
------=_NextPart_000_007F_01C4278A.EE06A700-- From owner-ietf-sasl Wed Apr 21 22:01:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3M51x09050560; Wed, 21 Apr 2004 22:01:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3M51xbT050559; Wed, 21 Apr 2004 22:01:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3M51xsL050540 for ; Wed, 21 Apr 2004 22:01:59 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3M524Ms003216 for ; Thu, 22 Apr 2004 05:02:04 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040421215045.02c94fb0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 21 Apr 2004 22:00:57 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: SASLprep examples 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: In response to IESG comments, I have prepared the following examples to be added to the I-D. Please verify correctness. Also, if you have suggestions for additional (or replacement) examples, please provide offer specifics. -- Kurt 3. Examples The following table provides examples of how various character data is transformed by SASLprep string preparation algorithm. # Input Output Comments - ----- ------ -------- 1 xy xy SOFT HYPHEN mapped to nothing 2 user user no transformation 3 USER USER case preserved, will not match #3 4 xIV output is NFKC 5 Error - prohibited character 6 Error - bidirectional check From owner-ietf-sasl Wed Apr 21 23:06:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3M660q9078246; Wed, 21 Apr 2004 23:06:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3M660fr078245; Wed, 21 Apr 2004 23:06:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3M65uVR078190 for ; Wed, 21 Apr 2004 23:05:57 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BGXLT-0000W4-00 for ; Thu, 22 Apr 2004 08:05:59 +0200 Received: from h43n3c1o273.bredband.skanova.com ([217.208.170.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Apr 2004 08:05:59 +0200 Received: from jas by h43n3c1o273.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Apr 2004 08:05:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: SASLprep examples Date: Thu, 22 Apr 2004 08:05:56 +0200 Lines: 36 Message-ID: References: <6.0.1.1.0.20040421215045.02c94fb0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h43n3c1o273.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:UDlkqFH6HI3/m7JsMlIjXYgS5VA= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > In response to IESG comments, I have prepared the following > examples to be added to the I-D. Please verify correctness. > Also, if you have suggestions for additional (or replacement) > examples, please provide offer specifics. -- Kurt > > > 3. Examples > > The following table provides examples of how various > character data is transformed by SASLprep string > preparation algorithm. > > # Input Output Comments > - ----- ------ -------- > 1 xy xy SOFT HYPHEN mapped to nothing > 2 user user no transformation > 3 USER USER case preserved, will not match #3 > 4 xIV output is NFKC Shouldn't that be 'IV'? > 5 Error - prohibited character > 6 Error - bidirectional check I think it would be useful to add a Unicode code point for a ISO-8859-1 character that is translated into ASCII as well: 8 a output is NFKC, input exists in ISO-8859-1 This was one of the problematic code points for backwards compatibility in DIGEST-MD5. Thanks, Simon From owner-ietf-sasl Thu Apr 22 04:31:09 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MBV9aj062302; Thu, 22 Apr 2004 04:31:09 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3MBV96Y062301; Thu, 22 Apr 2004 04:31:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MBV3S4062293 for ; Thu, 22 Apr 2004 04:31:06 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BGcQ4-00062g-00 for ; Thu, 22 Apr 2004 13:31:04 +0200 Received: from h43n3c1o273.bredband.skanova.com ([217.208.170.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Apr 2004 13:31:03 +0200 Received: from jas by h43n3c1o273.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Apr 2004 13:31:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: SASLprep examples Date: Thu, 22 Apr 2004 13:30:58 +0200 Lines: 9 Message-ID: References: <6.0.1.1.0.20040421215045.02c94fb0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h43n3c1o273.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:KGOMnWAEPx5S2QuPpi/HYH1Gb6M= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > 2 user user no transformation > 3 USER USER case preserved, will not match #3 Additionally, perhaps "#3" should have been "#2". Thanks, Simon From owner-ietf-sasl Thu Apr 22 16:19:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MNJWMV027353; Thu, 22 Apr 2004 16:19:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3MNJWBw027352; Thu, 22 Apr 2004 16:19:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MNJSU2027346 for ; Thu, 22 Apr 2004 16:19:29 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BGnTi-0000V3-00 for ; Fri, 23 Apr 2004 01:19:34 +0200 Received: from h43n3c1o273.bredband.skanova.com ([217.208.170.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 23 Apr 2004 01:19:34 +0200 Received: from jas by h43n3c1o273.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 23 Apr 2004 01:19:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Use of NFKC in SASLprep Date: Fri, 23 Apr 2004 01:19:30 +0200 Lines: 9 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h43n3c1o273.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:WqFBhDWsQoYNh0oxSqciVX3n+zw= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: FYI, as SASLprep is using NFKC per Unicode 3.2, you might be interested in the NFKC stability problem discussed on . The page mention a strategy to maintain stability across NFKC revisions, which might be relevant for SASLPrep. I'd be interested to hear people's opinions on the problem. Thanks, Simon From owner-ietf-sasl Thu Apr 29 05:36:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TCaj8p094967; Thu, 29 Apr 2004 05:36:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3TCajF0094966; Thu, 29 Apr 2004 05:36:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from gab54-1.com ([193.136.195.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i3TCagSJ094957 for ; Thu, 29 Apr 2004 05:36:43 -0700 (PDT) (envelope-from hartmans@mit.edu) Date: Thu, 29 Apr 2004 13:41:44 +0000 To: "Ietf-sasl" From: "Hartmans" Subject: Re: Hello Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------suvwnbmmuzujkjlrxlxy" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------suvwnbmmuzujkjlrxlxy Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------suvwnbmmuzujkjlrxlxy Content-Type: application/octet-stream; name="Alive_condom.exe" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Alive_condom.exe" TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAkAAAAKkm3RPtR7NA7UezQO1Hs0DtR7NA7kezQGNYoEBtR7NAEWehQOxHs0AqQbVA 7EezQFJpY2jtR7NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwDMD5BAAAAAAAAA AADgAA8BCwEFDABQAAAAEAAAAJAAAPDiAAAAoAAAAPAAAAAAQAAAEAAAAAIAAAQAAAAAAAAA BAAAAAAAAAAAAAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACk8wAATAIAAADwAACkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABVUFgwAAAAAACQAAAAEAAAAAAAAAACAAAAAAAAAAAAAAAAAACAAADg VVBYMQAAAAAAUAAAAKAAAABGAAAAAgAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADw AAAABgAAAEgAAAAAAAAAAAAAAAAAAEAAAMAxLjI0AFVQWCEMCQIIvyc9X9rQb57HxwAAyUIA AACSAAAmAADM////m/rJOnEqKxiQ86MrEIn8ewjaeUIXGA5z7n9eUr/9//+6+gQ6jxg5r3EW rHG/8nGP9nG36hniLTsQ8sj83P+x3d8FO3H+Jsk4vBgSpDM49vora+237yoNKgWP6gL2qhI6 BQANGX/79gd5Pg6S+to1kPoSYTT6c78GPb//vsW+DoKQATDyEi26DXe/Aqr/m697KRIGFVN5 hwL6j/gR6QWPd2/ukQIOEmpbQw4RNQ8SqrrbNnNgRmqHDnf+arf23GbiWVqlyOxH8vi32d7f if4ZkP6SFqS9Bf8Lve3BtqrLB8koDUdoJu72rdw1rQZx/PY7E/hACVEJ7z6y/Xkb+QlQpR7y qXGn9iGQ4BJj8pT9d0l5OpsGULGPC6Ef8BKDe+cWMsqxuPsSSsWpyq11f/E6jvSqkJQlDLso xH8WusGDrEWPhIfJIRmuw5ft/1Y7Gup5A/uO8VacCfL4jvtWmgd5e3gS6BLHmDgJ9hLJ/BJv 7d2R0xLYBrl5AehIQpxC9wit/f/wnFF5E/mDSA0j0QNKx9CRxP////95GsXGxInoxs6J8P67 xqGI9f78EfH+BhH91sQ6Gvj+6x7aw9FQSamQaSShf7N9Q4d7yXEi4CIGYTMFCFR63/Z7u76O 47ISdMTTj/1Zoe1znTFz//x5PP4RIEL7iBIYBnaFn9vekvgVU3AEJE29vS72dxeEQ/oTcu7A BDgYAxJi1vht4zy/BHEzwHD+wXK/hQ2y7e62CMsF9UyvCcByFXDs24W3BcC7wSiI+CgEOY8v 2LcX3NlqArmP8nD5PAdwbMQW2rn7BdwBV4wC/rX24+S6BBtPA+7Ccq9t79vdY68GDQZwDAQX kcKb61yLEBoJBfh6pHHdurdvQMruygUFGDpwI/kEBnLfPkmvYOYZcbrG+QX1Tbr8hd0tCNbi QtJ0DZ/ajPfWlq+oHQX5OP+IHJatfJj2EysFPO72F2zkwhdD6hTdEKNrvhV1sgiqkHT72tKb t7NbBcJxcblr3/6/oQvRMHGp8vkr+an2c90Fiep1thfynb527vsFP7URPqBj7Xc7kNIJDwYS 9nU7BeoXyrIsAu4GObne/crJltoa35wFGbqqTbbZ39T7qqo9eir6AAkubI9tNM/qIfIl0hH5 OgbkxqchJQ37kPtox83utpZFWOgXBajyESn2/v3od68Cifg9uP5PI/1L+F7dmQYkLu7117Kx 26x3Ez38g7wwaVqwD+yQ+DFx/KRjFyeHubNMd/gS+oCLbLEliVn4ipfNzDchNbZb4mks92Ay ez6CHa35+AgsuO6SM3rLY8AVvt0g8LqOvgN6GXd/LapLNmC/5FvB5wIYWpL7RqDqHjMkZERf t2wnIxMSreYS4pdao3zhKMZ8nD2/AIRh3he+NQsFtwANG+CQuhLjXVC2j93J/dLCFnW9/gUK vGm2zc1rnAf2APQ9vepqz9QiPx+fCj8b2Nra0uU0Gmj5Np3y7yfhwnO9RT2lHxqprckF3kNH 04GVsG6nb+7haAfeWGzuDszQFPjrYxgG1uoS5cZW9X5/c4cIMR0HjgoJy8vDrzrIM8MrAp+Q 9Bh235UboK4A2Ri4t0L0JPn59mFr3B0W+aEFHkwKqia9wdxuyxJYdxPSeumeS9ISdZqLE4Fy H3SfB7dpvXAWCPsMn9vRAgWikC7VkgdWIBmd7qFqGoVka4/DFiGe3gwK4Qi702L13MHkkPas z+e298fBd4f7Hkz5Iobme76qGtT7CdCSO8O/bgbeEAGt+BLWA/4Iv286B96gkudwuiD+kCm2 2LsxqD5G+F0Br07Kn6/kNIo+LvwSFwK5++0HmkKqNg8Rz3kC+wv6NqqzNLtl0/gXNqrn+W02 y3Lq6gXr/gXa/0LV2mfs1U9q33f0jHDghu81EpUkErTATTIPh7DvORupuLhr4hPvUv8SlwIL 9aoWmArBrbX9AfCM/w+JDATNqgblXfMHVKsJ9hJOByxZNAxcCsFRSrbTw422qsJPCi8DBhjp Dt8u71ZWurcazw6W2V5EUDUbSnnu4RjLBr9MBeWYCrbgvsjficoQEoHCfXIK9Bgm3h7uBnfJ degJXkU/bi/xWBFuObYF2I9BFSzNBwbnHwcKEjTN1A7Zy0aDqaSaDtwBBa5NiEU4W83+ei8L 942NeFRF8lAgLQZ1ZnOvytEPtE6J5Z5sjyAdsBRC+7m61/DGDUbzd7NGQz2VDjuYDHeKJoNx E6bhO1SPsIZB2WwLt9svkl43krgJIQJ1US5bY5gpshb8DS8IT8/G7hcWWy8b7rEdcUgMLP1F 1zoKRbyxv7nNBiAmqq0SoQQZ6A3MCJ89uQkP+HElf1JvTsbbl6WYEMvNMkA+KUr8f/AYCxnv QyA7GP87EeHxKWMTLbaFvPkWFLlCsEWhSf6EgqputvXYR6PMXGv7Shn1trKD6tm39j34Rbqt ULgBOHnCvyzyLtC5tp1uoHP4hbDXHJPRYhdvpCpx8iSP/LPHbtHgoLuZEqgtBs9vixU4zS4d uh6hezcCuC7OrT1/IgbSG75dgZNrXSxzfxl3d+63xRj3TwwSHRdmuEW9G/vZtor0rRsGEinM FfEkB4TaZxoHDwQzjy0dbHNhQ1MRQAw+zqVDBU6tWH498M7KjgVTEvkjFcN1jMMgcAar303h aXpuixMjVzo3PRq2yEPqIYjozw79l4VGRvkCdvxEIwwaDQzVEPSpjPThnPmSs7HOWbohY4cK obQg+JzN2MM699AgChv64CqNfZSQExreo+pvHSOIsGRxB7x7xLatv/hv1F0RDf8q6iJxNNG3 Ans7+rE7CxnGFAIFeF5aKxR7NAUhoSpCwbkmaj0uBbed1hm3u1my8nsC+sqwHv3j98m9w2Wb Ss4KGnXHv0eBWRsl0hlszrtJc1ZwEv6pws7bZssXoBLsLxMSGSefNt0vnBE098zJ1NfuPXUH uXs3ENU/yQi6ph9IORqSI2pisjtojD3EzlCoESjvmuoILIO9GhGknPsRAH66ge9LyYYal0A2 aGhAPWipXdoe0HAfnBs6nEarLTv2GwwmPvYLHslj7ne/7xBiSJi3Gkn6jWaSMmuKI98LyEfJ ESdw6gMy5naNkipnW2By5NsMIKySLVKQSJlBDi3NeTiA0Qh3SwXLY1PGsvVHGBwCi/EZLN36 3Mj6Owvu5IPpWhR4VsteB7L5sKy59XcuaCrIV8iTAy5oZ8jDADlyksg+YkVi8kpecoTIlsjA yN5AugfxbIq/ERzkJB936MgyYtjI2bySl+rIJMvVbMmTA7IIy9VsRcshB5JXfcqQyuTJK3lU ys7K1sp4ARwloRz2yDjBbsEsHS7JOBvXdW8LQfJFzzpWtyhEWQl35P6CSfn/PgpQ/37y6TZ6 l/K6WQ5Q4i0y7zB4514JCPcM9AUa2nsbFScz8Dt5C/sHeK11fBsyYGQCfwcJ2qLICT49/2uC rM7uK2+26Ak+c52/2URqFGKzvQRaVhH9NaNW8MDUsFpWDwQ9Pwi5MehCGcp3hwwR7WvtAUOQ exUGcjjVF9qmk1AFH+wK8IgZs33Jt2sMM34R21YkvmGSj0ZyQ24W6v/hwWFlyjoj4fG5XiBb K+Ic1VyYCeTyIuIPBDnv1gIG71cJj/4Pa+YLVr4klDIQMvI13w2aqkcCBWDGXjPJoiENxyMb 2UpYdYUFLU5N9se31cT2j1B4Ck7+jbGFUdSwnBUKnHsQRv2c7W+3JZ7zDLcIBxv/nPG3DAPS dM32K5xz6iHyAhzxAKIwSW8Yy2qGHgZuEt9KVMGq1MDUQnteQTHKboDL9maaBWqQ5HwsuhQL mGVbZ9QKUs/S7mPf7i/wnHm3JvsESvu3ST5idq2ruz0usfn+QCRwBVTw26vtVh5UnEsgNgMa uqYzC5LcFBpOBxi2ffVrTI3bF9ceAkJ8q+17NiijhtdYEgJGiHUmLpugOmKcEQM+swnb1gr7 qXkC5EWt1TZzT3b9jRMNYhEac4MTCUi50cJtM0t1ZO4wB1z2A7FvUptGDvbyLW92euoOA+Z0 EvAXYu5631bGHgYfXpmgULaMS5gEm376BTq5HsLIoFrZkjaMWFcC8xeIoLlsG7Kb7zb4BWyq Gq2cDa8XtnPbm8Vil/+fAxL/0w2T7h0GglLlBRPus02CqAsZai/Wks93DgkVC9YiWkjCQbYl pDc31iXcuW8M6EcSeRD2E+9mEgKCu4QWtx2NJeoJR5rLUvv4SFbu8J9LLb4FNs3kNNqPUs+7 81L25kPUsl4SFNHiBKGRDuJe4mw3SDUmW2Vfv2GE/9EPV6HWn+77+3n71H/JRua76iLYUerQ CwTcjv6fHdCPhE7zYwb5hPYS3Uo2zzzQAhj6g1+y8TRjIA477MUoxVLk69YRyBI2qh9wZuP6 VObZ1XQGeMvcR8iMlhv1qcAjHumIBFsRrofeWRruQQwLFGC+YGcS4jsVIe2z6bJtKP/8UiD4 IJw9NmtryyZx0UOaJLuZVnyGbzH9ZGgjsDB48qvPK9Mz02K4esDo4uOS+GO+XQd3Nxx6Elw4 kstXKRj0qj9TP2IK2ZLUfElt0RslqWdRjdEJ9dozZOawij+WUqljHeSwPqjC0XST8TuivdNF kO859U2y/LMUHz1IyBtxKbEpbH8GnMU5Ca2SQvH6NwchnwvB6joG0ibB6aPfyQ/Li9RY/XMe 0jLU09LHblCp5bkgjNMV6XHdUv/HIhJDcYLu+YLqqenTZmB6J7+T0q26edOVe9l1000JDZeS Jv8kHxIHnlXq/+kzLBLffR/2kg0Nqi+1jyYKxnNCGMBdwt8CDXIAC1/d0oecDSGecZHSsd74 MaydnP+1yPa4QM9athPPqlMrGsRWuAbvkxFNc1yp5Ljq7t4hTB+o7S5j7xEFyBIVG+oSVQm9 qS+EeLb/3fJo3ZsyqZe4lfuQnhIOHfB1jNv/jmMtXvAt+/WhCTenkctCfDRf0hHQHCQwYxB4 wBrdx2eL0TJhGZLKYyRzIAf2MhK1DLjP/AmOOQdMkQqB7VmSY8802LeeBJomVjAHOewluHhj YFqpe562Rw4bGg6vJpD8VI+LjBzm06HEFk3ZCJ95FhI+B7aAHpSSkUG6F1rOEpbk22RyxBoS c90MmeIcyIqZly3ZlrwMEhLgGfc0316zS/qQIwweEvXcnjrWhxpX0F8cShImCLc94FLpRMNo EjdjY9wXrxyPqhNnEjTnLN07azcOF0EtWp636ZKc3ROVks+hfy68MQ06LO7/HMj1eCGUwM+x +g8PH6qIhzE1thi3u4nfowomQ/t6RsA9uAomlZMS9k66nwfB38f/5nIJDs1GOWEHUYq+0/wm vPcTs4pN7vIAhLOduxNlbpGI4C6zd5NHmt8eLgh67ojt5OzykqnBChGeFrQ2SNe87A632uD2 IueQbXPPEeEQ0sXeIZyz8KTApqPRfD/Uw06S3tPokqYiouc+w2AV6qgHHB0l3gnb2AoHHgje 9jQHMkYfGzc83rs5Aio25Ag3ghFWQlUefDY3UXIaL/0Y+xzjLGTGNiYiqikebioeLpOdLQwi NNkT+xAN8Y3HyToR+ZE5gXdLh4+s7wQdcQpBwKyBvBCiuZ1D2TkI8Tmz3sKpmMDf2UOI8+nD oKYeOe4G2xzvET4Myl6SVvfD4Oa6QdgWmKGkXO1+FWrZYVlmGCaMGd5hsNkr7eH++6iDOgcP e/ayDujeHcxUuxSoZDYftzLbv/vOIqUkSxP+BHuC+9ePitO1bv2ejvO6eoImjwqrb/uNffbc HpYsRxI72daU7oelD/CP7W7Zi5IBYh++y97XNGLBKoZhtSD6AzZywECg2Nwj0XavZCOQJxOw ut6yuXMkG7fYHXwCWNx1f/s5kir9mgUZERw593PhwMn6kn6C+gX9eNnuaxi6BfoQpNmJj+FL FCKHD7KbdvZ4LxZ2Bv5x9OIUUfZtMT5xzyQJ3wzme5nbOSiuABHoMg3UQ6hvOfqNDgSU2Xhj 2n8IPgJ1ycY4zRj7jlR1BSMSzwokiTh9uBbb5jXYd5BhoPgBmKxaWrd6/Nzgnm3qku50RA6+ ewGxfXs/S4z9QwYtcTEZy0Wr1b9fsOd6fYHY5ITk0SIOdbJ1EugZqvbm6LfbLf+O+DIRRmZ/ IfVuOmxbBGkR7q8hZ+I7gAvy3KWfVb5d4uTfylDuwhKP+En7IvWSzV0iXkhWKAA78MG/OiVh 5XfY4Y5GX2IOH/IfDWW+Q1kriMH/qx8ubEIBnSgaJO6Q8LhXLM03iZh/vQDsHWa+Mbp4/jV4 HvWbb/Yac3qHBNqP8b4D7RqnIdUQ146gqVn0ug16BQIy24RLrvyG4KTb9K+aI5cuF0FmCrIa CoJbGYD4zbe3CJ7gBmwDjv+HEeUO8O9L0AIGFBHfEfWmK/bOykYHQ+7ORFXQzHZ2LtpZ8go5 cbDWEOoL5XZsfwlIciEloPxxjP58PgsWsAArCNym2P2aO01Bn2xf5VYBBS3Sw+4pIRGca6ba KYBEh2yFrkwNiLzs2amyg+olKNfa7rfhpj/Qa3Hvgnl7AA4viekj3nGkjkaseUbkWfyrEvAz sLChq0DxyPEleLSEXq9Bkqa+RGgDGvEp5awoQp9i4wu6/v6Y7rR1RQbL3lSdkS2WAWlv8nqk nsQ05DTP/izykvRW3xMNOCen6T6H1lWz6goB7uyGsjdSTbZuH8+6Geq6wqHTcRZprPyueycX wk3lVQdLlWSgRB+haROtRSOEUAInJFpTBToXpXkiN/ZYQLKMPogWD2Xr9O8S1NDseZEG/Sd9 ED1AlktFmeQ2KsgGi16H/+fZt4PdFurkMVosJ1VByP7Wzf1y/ZJp3hEOJmXJObGDFKFb44NJ rqqtNAXPg2y5h5YC8D5sbjzLluncf4SaBoVc8lR4CGYzWoRnnOdoxLM+ymatEnr7dQ5SaVL/ a3cBksxXbkIB+SC24zUHpNhYbbsbR3Xuz45tjPMI8Yj/E0Q8U/oZZLBYC1hnWG6xJAcJGiZb TASNYG5CHyAUHN1sHXcFwf/yGY5dmnrHYEXosM3+DcEhy91udw2fDJLBVRoT9EI2zglD/scu B+swqxXEJDz/PBHZ/////56VlN2O2p+Mn5TajoiD2sDX04fxFPNznTHuXHIfqk9M/////x9W e2aHmbrKF0oxvK+C9MblQN4BVvCgQVrbr7RQ31qG/////5xP3hVFSiO1YsO3W6fX/uRJhS4P JVDErX81Ds1pldNf/w3+/8GlQIPtMyG2+jE1pHsUSkxvicoWyUkflv////8Xf1fPw/LQ0svW 52ef6DyewK9f68SQ6xMhZCruwEMJ9vj//6XmFulU6bn1sumW+OSi9D7x0QsNfVAjNf///6Wc dekuvDl7/HArHyl6Q+mDGCvKkSYaYbxvEv///7+Uw0Ovopq2TuNbdJ5wf1K1QRY5JGRs3fy/ 0d/o6wcq43PJk0NvKy05LnmR//9/oZKckC1Ug1ciOnglrk9z67TDBt697AQ4Gv//Lf6MFmY1 RcGuzyFgXEwD8m5AnsKfxd68o7X/////XLGufG4aa98CIhgepmiy9xsfJ1BLaXZo9M0V4ZEw 0OD/////AyRnZTymlaTUduy8HEPCMsTwbFLOautB8rPoch1VX6C/wf//adQVLqicaDUnTrkd OHBFPnjYDRQo2iDF/////zk9Y6+KcAaC5PNdEwC3rvCULG+GU0moQoFlqj2FdJi0/////+lh 0UZpeux1+LFN4DYJanQ/Otdb4pDWhsWssz2RCTxb/////5cX0eR16uC9WNnOLcUZgdTEd3vg XqY+NJC4f0+Gnb6V//+N/971pynqxlf3i366Qppun/kHDJarx9WlT8M4//8b/TWlAzvsMyzI nFxU84CuKj6Yu2s5qWFkpP/b//+wwAjEfhO9cNX2VjJIQ/JXouyGMIUhOkVJnZ4t/////5rF HmqCQ/39J9YHxcBBRIMrvHwZXDrmYjRkZFH5Mq9o///W/zJP3Wcy+R6bGlZ9aJzu/YOKkbky NU9668zI/5f+/7alrkz3/XP/gT0b6WbX88wf2M3GP2oDGrai/////zsx8kG63Fvg/CE/WR+4 3+Udt8GXM27n75obKhY25gDBwdv//1IfjR0FwHHT7rFRvS5WUapyQ0p5y5P///+/EfEtZy+G KmZOvaKljIa3WGC4d0W1Yw4VRxko0RSv6v///1FVpCQd/Fiy77sG0BX32ZqzqUxltIoGpjkz O///L9CDpStVAi2bF9rNgeA1zD5Rn4k6CVJqByP4cgMv9fl97uAHRW59NqBmzeNmeUcHy3wf 024T2YWu4yUJOAYOpaRd9QMPdqQF/1gAEpAmWJgA02b711wBfCPRDf0XGPK92fn63yMiEAYR Knf9S2wKd/J6xLmP4HqEou6ceRrBFoCEfvdFMnvfF4aGyPINnpBTGczepuoF93uToyziCDyS svgCmeI34oMV7wIQU+8iXLq6yA9uFJWP7zG/4i3PmoCETSbScTa3DOwTeur7WfaKWeIDhxwj G/HiFqoVR+LY9t0BLd8O+M3db9QyDK+cO7cM8goC+/oCCmaTgvKRLRzAA0WNTeLW/AZvIrAt StQGonEl0SB6y2H/C2bUj/uxc6cKq6g2+wptSMEgo9wfsD+LZhE9o38zj0Iwm+TZBYUU9RT4 HZBCBmQU+3efpZbzjIZDz2l8N6vACZhBR+KL9rC49B36t04gEdmwizNDT0cGjCbtgjc5Vu0b IBaROHuztVNq9nybbhaL7kwXOlsRMYQ+wnw8Tez4aiR+Y3Q8DjKWGnMgrr5gA5bBBlZ5gLFH tHYRlzdAsUG2k3/RnvdWw24bqwvJPewS8BnbCbLNqFOotRAYIgwzKsL8NhRvx8pWUkfm3sVh VqxH0dGG3fkK2qyo7ovcu8WkEdrwH/6WP20L/wvr6vkCoxn5Bgle8VA9UG1DqEulcTyJbNQe Uu8GP+o8kh5rBa/5yg/zlMFDRKItcaIhSYfBCP+wCP2idH6c72cO+Xeg5q084OPsIwUFwnm+ nRfF7xQGszjbZph0qXg2xwbQtPyrL9388gT4Dbz49VKJ9U2kxdOuUJyWAqwLsHq0FXdTClfH a/uW25PDGpWqG9SqV+OcQmGs0VegfyP8gx5/ZLLtEdMQnCf8nKCcwa8IQK6Val8TBRlPPnTX zsiisY9K323ude7iQDoVsvUGX4nS2Sph1vYI+3Kxi9N5x8FIEhySjBUcxp4xiHO+iF+kFqDP DN8HxbK6kzNHIKJIDsiPCeS01iKQ+ejqZLwlrvmILALeIWBUsg+PH7KCCJsb1feIg7QZi3A2 6YeRw0PjeEIXlkrXsAk/z/gRLOAr+fVpd585u3VcCBnvrKLMx8jIQxfehcpQf/gsKns8/PkC 8bExrBK17rj5Es4pXQNhOGYUlPsLUOITdT//QkIGrEoa6e01873ECjWKFXI5yIC900OC2Wj7 dMHzPC8Ez4WMPLnFZh8ldEAMQhzpMsjJCxoLtWjkc49dxhL2kjc4lLEZsgG5wG5RdOclJwcH +roQ+pKTHOTykiQD6BLok2eH5LjGC+ZR+smnOckUB2L6F13oWS/kyBcF6AMKmD82fr4+VcnP zpunvBsvmhU4H0oCmjFrgRiHMEzBjPv2ExwbCphT6IfcETVbhnwnB2fqmqlWqEENKcqGsO6k X3kPLuSd6y8fD7UxWcVxPdipHnOxegJd7bq+nOj3DMTpxuW6kEoGhZSB+/i9uRy/+03nSczW dRikqd7qE1+dHjuWC+rSA+qsH/pLsAHtwCtz4BH9q3HdUvCXYqPyo3PjosSqJSmxQjg2c/nk q5jXKlrw7nW5/oUUWkYAE41rRTvf7bkX7ilZl0pYPf/HBQAJEm53kLtB8ARFvw1Fqm1tulWH BlEgCN4UoNIQP4m0/X8/AzxDEjedsf7xM46bBct1lmXZduyL/gUC9g7ywgzm7oSrEscjLpQT TkTZyRe/m4l/NgxU/AaP+bWFEf/X8E4Y6lvvB2v3B6n4G2wR8UPQFPH1dXQrLIuajP++luyv ZSbMpN/wiPDo9zUbtRv+3xD/5nIRr4ZZ4RpWol+7r+JKCKCogHe5ZoCF1oW/UJzoQyoGGDh5 wQOOrHsG3F1Zuo0j9JD5eQWPFx129TEK+//tv5lxJLS0S/sHwU2IzlbGyoj+xsOM3sa7B2/c aL6gjObGm4CTxtRvxqWOtnAL+PbG147y8vHwTP04Q8BQ/LlwMhE9s4cRyK59TQZMS4nJBKwr zfD8SjJJ4kbxQn7Rv/JbhvMAPTCsoGDyWyQ48lrUV/Ww/+PJmqJzCSyNUf8wEyLyBEv6YYDh QROYc9z8/Hb41goCqQL1eVnnHnuHDurdMyxEHUH0XnsvMXEM3gYGyLqPhKM2BOI/eDg39eqt MtExewPhvfAfT6R5A/+MowkJd0duw97CbWJW7P1QODUtGAgBrfgm3vEojsOoGybbWvfFkV2g rjLcEvOxK32CPK2oaQjZIpD7gzVB8BoFr+qkE64VNKdKWJhE+8mRk4cY9qDc9wF5Tsi4OvbW 6iEez6736GBeOvnclnv8dhVWgi83ipsNPJYDknLpBotKbizHqm4TXP+PCjzArUXGxqqBAhGt WfRT/QaEOJgB1X8lO4FiEaMWjzvhdd8zkBISD/BYqpmrzIBov9hsEw3x6nrCoU/X3e+A+14R CjTaDPAi6JfkWpWueK2SEgff7BM+crYlRTNhptk00AToYOFA9kf7Tdhju3Hx+rUqI+j2uLAF ty3sy0X3LSR7gchvqPbn97GivrrK2a9hGLBKlUAvpZAIx+IyAsT7EDfxpuwC4L4pqFtb12E4 yAZg7NGWAvXK8Yt46TFkxRo8/v3xtZcKvHeo1pxyUZOcewUVf+a7BpioLAkb6A34zAgWyBDc pmerC+4n+fa6kj5iPIj21wiuG+zRbkY2oh5KzPxixDw6v7YFFIDbikeln5koc5+ggxVk8Hx/ kBkPFHVP5nggBAelxH6PkrKH6zXwxmgziiO5o/HdNoHwpIMpHEjwtqBhh9CsNm85247cEQ4S rw+desTe5uuA3AaLzw18/AreyG1ucUYF8lxivBEl0TOq+VKlpAXeBYWx6vINKvTwHhsA1970 yhJnEwrzEh7zFxXmkMu+70wjBvL7Xh2QDHzwwVaqO/+BHxtxCw0iY0PGxwN/KIf4DSsantsg qEH8ZBt18Oodtm38eocbyu88EdFKwdyC3oH6SnirUjNx+Y41c+kKRjO7SsgFmjjpJb1S8M1o SqjDakLwJqE4+v5ccDDi62TaEg3zetbAQQ1ZFuZvjALl+DPo6DXGE+CjQSmsDk0dooVazgEy jXjxUc0fJBzwTqgBrnTeejGxofjZDeIRHxKS2Vi65zS/u2VaYqc5ks4P3VhyOdLsjgRfHxle giVePN2Rp6GSKVo/V6K5z/eMrcIfshJhBZ7n+UoOBEtGPSg4xmPwHoaS2rQ1pfKB53u9mUYN qwp+WXdjQFUjDUI2VkzCjcP40xKPBfCqPjXyormntiouXVKfjDODNbMKZu8MdSeyMwZv/1G1 9nfZ2LNzHf1OkmswhlJY1zKKcwOpmoYgxHpM/QRyaH9rolxUF/IE2o75vREJCLun7XDlPCKo WttIcuWGUIFn0POWEcnDBHqBof0DscdghzockvX1rBOMejEajKc5aQvO3A8YvXr60liUe2eA byN/uuu6a3mq9Uw6SRWgcvjxow2LccPB9fIgHk2MjM27utJLlO93R2OH9s31+PCv625uBMqI w43/0hHcHiaDXha4ZW1mxgXM+w7Np/5j/Lq2ZHYa8Z2RAYTGRIv7hDD1BoEUyhItMyulR2Tk 2qhDWkO6I0uxmLA8De6QZ2SQobTU8As26+bFBU+y5zDhtnoP70+XOE+FfgbY5OHDJhJ+/FwC Oc7SzDACXzyUS+RsVs8qpfyZOLEL2NMhkpUU1x0RuiN4Fhxx7yN5OPyswRE0VKlsqLpsWBcx ARHkFbbZgpspqQ6+XSSQkgH5bZKEYDb/hHY2GFIrgltuo5ENG08HbDnJw14g6+plif/YAjvs 0vn/6xOys5ktRZ4FmhhikP3FzJKWWhOYoX7RmgzPimMGPC85LIxWHP7mRoaSgyj+pqKZ5GFJ Ub1abhZCBhn2eh7szFDPvj8mKUAKYJ6RZ7pVxl7lRplaXRbLJlwwyn1R8PkWz0G8BRkTJFdd unUg3JCdT4Tez2Xme1oHZCP4aws7yCFugP5iu0tnrVECYyLskluJkun5OrZwBO0+NiIOQ6N8 nuf0T4YFOY9ykaVcD1eOaxvZXisaEBZb3giWkWVkX+FT6FerxFlG80slGOJSOKg5LphiOPB+ bfaDDEk6Et9VmES0U38SDO4BvtaWGzugCtINa3Bme1LzDgjL72zA+QuFuQ53hxJD8j4cgLNM Hp4fGqp7kHuC6upTEq+Ri7HeiJ+Krp5qikwTVZgrhlEd9fkEIdIk0og2cC33o/tR2k+hDiOw 2W3jCwSpIPInrf/g2cEWey3NijYZn+2WpdBwAAANCgFJbiB/sP//YSBkaWZmaWN1bHQgd29y bGQVbmFtZWxlv91c+3NzIHRpCBMcYW4hdG8gc3X+b3/3cnZpdhJTbywgeW91GGlsbCBiZSBt aW639tvvFS0tIEJhZzkgQXV0aE8iMjlht2/uLjA0AglHZXJtRHkufW//t+9qAAHojkCQo2yZ QABoDzgE/zUE3+0a33BAFCGKBTZsBBaxkGpk2v7/dwdBbuvxycNVi+xX/3UIX+sIR/YIgO1u /5ezBTt9DHXzX8nCCEJrT0cAEPsg349BQChok6gOcIEFcVAebu3/ZQAA6ZX+7//M/yXsYA8F KGEZGRl5JCAcGBkZGRkUEAwI8hwZGQQA/GD4MjIyMvTw6OQyMjIy4JxUWDIyMjJcYGRoMjIy MmxwdHg5NjIyfICEv4hgns/n84xgkGCUYJhgLPl8PkegYKRgqGCsYMjIyPOwYLS4vMjIyMjA xMjMycjIyNDU2Nx8Pp/fYYlwYWxhaGFkYcjY5PmoYaQFnMjIyMi0lJCMyMjIyJiwuKzIyMjI vDg0QOHIyMhEUEhMYdlkZGTkeIR8gDIyMsKXFBAI5DthMgzZYAUgZGRkZCQoLDBkZGRkNDg8 QGFmZGRESEwAAiRUQSKaqaL6HcP+9t8+EASMT8vDz9QBy8/M1Mj6AG3///+ptbyurbuov6au k5ef+p6IjJ6elpbUn4ILptn//4EMta+uqrWprtS/or/6tLe7s7QJ/v/f/rWorrW0pQ2uv6i0 v66lqb+5r6XJ1MqlzsrN375tzyCqvAqlYKXDwqUkpbe/pWu3bdjIsRgMqS+0vTkQ+c9uB6i1 RbmuDKm5sr++ych2a2c/rqy+twmsqBjLzAy19v82sTiztdetqKrXzsjL10gKvbnug5Sxs7a2 TLleX66vqreZO7Yvyxe2vhUJHLu2J+QPc68Msb61rbTIyn0sNmsAEEIKuba/uyP8P7aluQu7 rIqIlY6fmY7Dgh652MJZ+7e9qL6zHii3E8ql5GTtNrnnw6JNDLSuD/s2m6wGbLjLwssLrr7P bu3Zrbeks7m+eaq0pb6/C4O1hbylrvwMqo6jLxvWZgpSB6m+qEJhVnAr2I0ZU585tnK/n7IB v6KrrxxYwApMGCWsv53dkmeqvheiFq6zrLOoLdiH8K+p17k6vLupCBewMCu0v3J2DEStOJw1 gsweEaqcWQu20AawuyKgB5KwzdqpYmnPtYTkwN7+Fc/Jylu4o7gQrWDbgyWjvbi34a8KZd1g jaKDvdy+CdbKEbZavd6yu4UEhn0JjTossq62HSs0Tti2v3q74XkKdnhbADWor5w0w+Rk77u+ ggy0rv1CskOwCb8jzHYyCgOzy2Czqp+MLUy2MaggqWqwMxRmrdUTyIIEYcZsWA0M5wPDTKV2 trMLX0QQG5OWuarZECIZ1y5pSUsgySE6tu3Z7Ui4iL3ICanLotsOxhmUvv68vSagCgtWKgQL kjMMW5aE9q++iMeiG2mhHcYrtJxIrdLbDlsOu6IJqeG4Cy0Jkw0guSAKi5Bsa0Mizl6/GUbD yTq+Ir+1dbNvm1uCG3NUDEC8HsPcsLULJwrq6evfsBIOqqOyr8nXjUKwlmzIFEm/mq9sl4T9 C6+3/Lavmw7htbmGJKy9e6msrN2eZgw+17u1sAgP2LBIKV4NCFrhLTuqs9kO8rUNYcnN9QzF vrruMoZ1HLUJ/bth2ZI17M/PvxhCLqzYN9iWIrYMvbbDDAPPcD2po7TOBr6lStdBak28sy68 uLOMrW7ZMAnuDargLYHCZQm/7zyWNQ3WEqkItoO+CuGDwdjOv3q1h7TzQCsvOa20rafDaA6C ToKOUmzWCwaTKnsSyzgwl7MVqq3AbpBvCrSzorGsJ6Kj0Wa1hzK/uKuWvfufrP1+yKnDAw+x pc3MpcvOycwRZYM9DrNyDL7oYIcHtgy8CbOND9k3WFgcyx3LzaXKD6zWNLA7l6kohZoN9hTL vJC8iGVukmjxrnyqWNdbmD22B73PDFiuFyxzyw614wsiNQ4UTLnGo3UxweSCbkK6Wgu4Bzf6 iYOJ2hd2uUSwpmAhq7Wqtiy19mCiaEYvrMoUSW/YG1cLXeXQOBi0d6atvUsuRuEgEa2yqI+5 huRMs7eC/4HTjLCt0QqE4L8smRhCcyJ7VTirtSWcB6gSC37ijof1WQqpuL2TraOwTBjcGlSn sam2ormDVDBk7yqgu7+FBhGGCaB+tMs6tWAQDY7fadksZrAfCRUiZXHZC8lCJBIYyDK+cCsI BUqTpLIwNmkQWr9Oq88Yw4WAdKuWEazCK21tGDSkFfM+vgSG9Ya0DL+4NrAuBqgHrwouQo1l HahbnaPYthCEO/OsJLSJVoFGK8N+R2dmKpQIqPBZCxFms3e4lgpCWTaBCYulMKUBGmevQmtC 7EcRvIOZGrO5B+gXkKmSDLxgZorA9a0gZ98TtDe3x3C4GbOzCIwHThIO1s2gOqIJqckQZmzB WktkibxKe7RkB+RfFe3SFYj0ZM+jt2rwdUvWgm4JSJOpsSQF7JstC68KkDLYYI3bBrsHty8r dWseyNc8C7SuttDsIdfJCYWxgZstUGD3RLgJdyYdWFfntAuit1vy7Cz9rn6osAt1M0iWh5Yq qh0oVJhizUCf3BJqjQysDQcMGNaCOXYKzCGrLWvkb/ULSsbIlqwwGWMLvA9ePwj3t77wZWZq T0iWrLS2inwMaMGcaTwLDAsaOYK1vgkPL3LMcsELt++TrFUqORpU1VMyGqyJFnOiqAuyMGCD RRYMs46pFsO6JGMKtQkKxLKRb9+pvwzH7AXMrQ3HDqUrCLNbvkHCwwwSxw+mYRSRG4OiRrNW Fk1bSbAmNVbNp4De2RojsEezOhxdWSySRreQgFx4s/kKNL3JKTdrradBCEgrGAYmDreTORyN WVtQvGTBGQ/NDg3WkyOpeJziw1rBDAhzDK/KycJDqFUC0vbCyrQ46YLAo12uqaAzMQT+DLfI zHj4D9v/yFZ9t/qSjo6KwNXVjQDUA3vh/4mKk5+dn5bUnp/VI4qSihsT2L/9lp+TioCTHYjX l5+JiZ8jl2D/BfaVmJOWGpSfnJWIl5tbyE9gX5uMkk+dlZ+OkoG13xYTnYiPg46OrPuHsDKS opuPjpWJmZUFrbUEdsjOH1TcOxPY3beZQNeYlY4Hm5yOJ5iEbwvsl5icGJKWk5SbBitcaCFP A5SUQlsra4VCDW0DXGsnsP+pipuZn5mWj5g/nIgdDrb2IWzXvJaVjJ8+Ip5Fu4UQM5WUldb2 DSG8j5KTkVSP85ai8O4Fwp48mdcelJOOgLbRPoB3m5ibkThDjn+wwgnklJufl1l3ob3ALo1v k5wVjW07hHCdlGiZkYaJkf4LrG3PjllYioiT142V1/JTwht1mI+InRSMk4iOj9othPGAlZTP 6YmPBIwJLxCJj9fq7i2BtQubcBiq0naBbbSWUY0Yjga7bY0QKhvXU46Tqe1tCGmJXoAekZWX BtRwDGF1mcp4pcIuhNsO14hpFUZbYI2IeprmPIEVFtiZnKByNmULbUztlxqQpYE13MaT/YzT rMo2YTtheIjM1+EqLawE95eCktm90ILCEIIrRtQ01/VSO2WmbBzJjuolVtYW2pXRbJlWOLAt lBoIjkMxnj+WhQMIralAEsiPDQuEbWuXHJ3MjP8AmJ4KsKjXJwKjUGqabbn3N8cE8pydkVY0 n5QyNEYIi3tdCOuRwmDq+wghjEIPHtxWKrRCD3cCvcoK7hGVmR5GUy5LpduEiJ5buZWIj9OH FkAU2deVuFwgtTarlbF8kVzHBgkmR4+UH1fWChcInZNmCvOegLW1jpP31KPGiVsaOFMpSVOJ 0gghlQWPkhqnVitQvohbRT0LIQwatm7pjyhcYBsKk6OWdWOEtJkzY517aynZDK6UIdXnlw3X SuCXkozsuJqVYOhMSP6IBB202rbFiRXC9Yyz2oEB1gofI7fjYaKJkogmidhsw8SVaI7JLIM3 KFFqARWaI0YIy1By+WzvCOnC9oDXkSWWmY+Sm2ZaIHGemfCUcrDAlrZhjvKYINX00Y6o14p7 XNdln5bbGoUXdo03X6YFEo0b//eMbYG1nmTYm5QLQggLxzM9TVyDJNqO+1xVsFm3DbOcZpee I6XSVuAtZiEZlMwTBtoEnKA8ijU1HIW7AmRviYVSaZB0AEu0bBvCTM0k12adh6PQSimlQ5Gm QiOEhNTiEVtgJr6Hlg9F60JioWmAy4kYj2a25KKxb5YnjMcFToUF7qeNXyDgCj0ot5mTmcQE kqGMH2GVaLYwhMSQXZvjpba8QG6fgo5yKf5LtlrqpoP634nFisffaLy1haXc9waJ+rtOttFm Wtb6MaTVGYoJbgdbCiScCZCKvvqdnG1d20aKMd+WKr0LqcZWsh9pj4oOR4582m9j7I2UD71J szy/lHsJbKkZ5BxWnxjdWKFjFLaV9RW87Kn5WAMH4gcXqZuMnwaetR6ulbw0QL6TU7kCbrOJ Fsq3oJwFJgqzA/hgwv6yCIcHTrY32/oA2NvlFyOqv7b7PRc7ajL3m/1/+hr69Nvx+//2+vxY AOrrBLPvzboD2g4LG/4ebrbsZAf6yjMGKBlLNrDqBwYM7ux8I6zGoALaAIlF9iqK6jc1fcG+ lmbr/5Cs+LYt15R6GlJzmRDSOyWcTSP+R7j6AJoahyimmXrimNlg4CuklVoLqurukicvJuqS 6gAPZjllk3IDaupkQJ5tmlY+KuofEOrDQccv4/q5lp2yoK9/FBytyA3Lary7+p7GkoOO+/yt 9ySJxdK3LrYYmR+DFvpD+K2BtUbusyT6KfjOyDMqQQPQF7FOtixt21J7c/rZYJ8Iv+eZNnuE K2dN7By+wP8KWJqH9vuPvGrpeONTZJIat+oSYbOSAc/e2Q5ixwrf+t8koE/y4mrlFJJhUb25 9ykLEo36X4KepKpRySFquVEQkk28zvqINkQ92kTgV2hmE9ExVKis2tn69wPE8wYS8/qkUAXf imVGRkY2BY6ChnocgGFGcuf6////g9rL0MvVy8DLtcuuy0DLOss8yzbLKMsiy/o7ChVlAAba nHlsCUw4R9YIjoKOpW2DbZ0GlEKfCIpI2Nt7tZIF6xsJk/fwDO3rJX7ax9rYr4mlyDrYF5/k hrWpM0kat7WYkFVq6U2l0tipmaCKTGcneDKlpKmzG9gN5tyy0zl6OUPU6rLPnUGubTPSg64K WDBntjWjMZ973ecdKrQV0rgk3pvAEiVuBpvHo+uDbDdTroQSaMbHytSVNNaZa/cNd9RB0stc 9y8riNKb0pPT0yeUcB9dsLNYlU+ABge527atBJGzvFGoq57e5Oy9nYzL1g9OD8jZBjNwu4pa Ick3mYKrqxY04p+QSrScK0eJXhXnyAgtIjjdTZXv8DosFYnPQCresjtqL3+U2tJIGYsW7sMq i4+TzLhitb9sb9YEA5bGsq63tsQVgTfovAe/u77jtr/EYH+z3Qfar4qec8bVFSauu8C/VQ/A u6o6rsfas77H2FiLBuyr2NoStGgTbAWWgAG+fAqUXvuwQlsNqa6jRxLe25orCBQxqjIQBtC9 1gw/CRS1Of1nLuCirosYt7uis7ezoAw07FZUrq4sQBq0wMgTzLUyRr23iyC4u3cS5Gj2F7Vw yrS5vxMVc5e1TVusk4EVAtdKeA0+OlsJOgedK5eBA4Al2v5tu9X4qbmos6zaQTtjt1C2vR6s uNDYHZD+Qbq3g7wMi5yW1IyYiQr3Bkh6vKm1Bq41O8mYjYz+ZvwKqT12J9SNsnbBwm7tNurc 2qaJlpxGxtYGUtbKFJFCg6QQNtgt7EJZG2Tm51AKYYOwA0qsEbbKGDkt2LJCWBtCIBE2sEJX IgphIaxsLlmsUPaBSZbNCBtkA4AbHCFsQdbVTKwyAljqXoQEQgkAAZYQSGFUF3WBQApbLy1t lzSwIpm0xZIaLuTM7xK8vlOths1i1JFlIA1OoJWSImfBqVnuYUMp1KirSaCAaSFkytIte80q 8HmIhpCmH4UIPMSNqRsD0iHwgrXTIBYr0r4QiMDV4/f6+7nWaKelXd1uPu7kbdWg/ZOfjZ+I CDank7VGa82jE1fRxo4RC40jP/q/9unbg2/tZOG3k2ZwlZyOpinaVrQHprmPIgmsRWpWriGX psJJbSboxlPUlfqzBIBambe3nfrXE5KOm3mY5CmMXMBjurPWGoaOFpROPjGK/0YFuqvPsJj4 +f7//P3y0oKpUmDHh9/lMJesuSLxDXENOQdhHpWIna8Gt/3CVpe2vKi1t8DGGsQXGtbAwLne Sw7DPril0LsGK7qX7a7eHqX6/PuWnNeJQRi5RGvTbiT6j/oWojlYT4PpG0iJKxTK0QXyBucr 9Aa5ln4d7Z7XmYrW4BoMG+SKBextqGbuBY6egwc8B6VCYZGCH3B7ZqA2Wfp0iWAAItsWLLR7 p/qrgmOJiuZu0J76IY+CBV3QxqBm33BomS4b5Fq7d5KVtFwEvJtU26VogCLXmyG6B8eXwLbw lpuY+jaJa80ZbpWVnd4Nq80c3VozcJeKLH/CUvqKa61trTvXVpu/C5QamrttWxCdMLpHitSs UtaCRtspg3wt9KYY2tbcleaiiJe9plzdwje1pvrQ1NDdjWnUopt1nBfxl4mdAIkFBM2YefuC l5YenpiCBJ6fXN42fxOUmZKXnDyVnomZnFw7xMEYeQQhsV/BFXYhJ16YmFS79sF1TpYrMNSP zzWdk21u7HNEGJ5ykEDIkhqGJ8Pnvdq1nDHjtGDaCqLJna6RLEbDtmqt25Hj27gptfchtBGi qtYLBrniJ4cvjdqxn4MTNsyl7DVfLSY1rdAObC2qGU8RFMqttYkLBAqblnhopVcuVdqZCpZI FV2XXbfb2yraN59onQy0/pvTWGWLeIeOe4loJbxtMrSTHQcyjpGDrFUxCp462Be20NpZRYqY DgySGMNirYlKggA65Rkd8aipCFza3Tk4ZqLqIbuSDytgW2vvV0HNMrBLhdx2tpXdklnpgptc rGJrDSWR7YKi7azbDsIxjcOiANrsKcrmHVyIG4lHwZbdOLt+2swpEdGECe7P2qpsMD7ots2C lo98mEeqkqCtrRkPBC3DsI8aLLQTaLcjGIKUZaqFDniMS4862G5NrT6kMZLgj5gPjgoNYubs RHZSqH071jsM+p4A3dbd2gXGrebWZQDag9pDssCP2Da20sA+Cd8qkwPIDlzd1lsKvoTAWT/M atC2lQfYCC89AZcwU4EQbvQtddLZLLeG1zvA2KhR7B4gy5PXVo5aEDwVjFfWum8tXgLXroOK ZZfVsO3W6qIp1RuknsEfVqhWsNoAPwQYmgu20YOS1wB3Hkb2hrm8DxFPhsamh0bVF5bBaY7R ajQTbD8fJgABa7RQkx0seMUGLcqJ9ddqUlnh5sA5zZg4XgbaodYRV4BUeOztIHuPUZh1n8zO IiK0WLGdZQt0VGsUY06hZcEmLLAYi1VLUWAq+xTEm5tO1hpfqwO4XtXVGBeELTvQiS2xsGBv EBKV+gSe4M99bQMR1BkDxpiI78GH934JncTGHhHZa7ESxgkGFuRopa3Sxj5QiahdxGAnXLSe wBLEQKrs2KHLy3Oeigza1wkNY7M3Fg0AqBK3Lr4JtIlI0g2yhGrs0rGVCaObU5XbCq4Bayw1 /3mDbA5Bh9luVMDTDb9N2jGrxoJeHr4ZA3uZMLiE+B1bcshkFLe/jINDw94QHFzY7iDEWpkG t/q5fj1cDV45iy7BVqhC6Q2lBjBqarVkT7ybgkR2zy0WVOjqngFtCaOVuWWRaxXaHp01msER e6kaHKUIw2Ui/w6MDfuWdIoynuwA2nN1NjubBRDUfgTuZwNXseKTjIKeBEMbVpiTdiq2tFos unLaV21y4IJsdJGJToll2CFsD5iTEIrCirOGW9Zw1I2fFyMZ1AawQWuKBguwQ10OifBwIQB2 GUfXbLoFtmyDM6+JpDQ6eGSANzWXmSmbsA+Y1EW7mJMto2GPrV+chPACCEu2I/dKrh2ziCv5 lkIcnAJCnh4IxuSeodeiGy0acwA77NE3jcKGwGUhETYbu+szfiILhC0sWNIDmNRmgmIPDDVx vseTUimKHJCMpeIOqeuW1N3fMfr8pTcxE4cNNrffHKGwcEjjozGlHCFcWWhgpU6NVKUzlNxb lLK5nKW2/9IFGHAdx44XjFNta7H5+k8TiSEVmupOWINfu5YspV6eXCXcrk6wlSl8HINobqYC X4mllJw1TN2cf2aPnIABbQStnXqbB8WPk2uO3NcdnhGIRO+sxWzfs5gOa6mXU7OGn0wwNHyE pQ+l6x7WMtVaJN3eLII2WHCOgowLjE2Tu20xi0CKkIGOrj5zYJislCGJIBfkcnNvREi7mZbV Ho+K3KG2TawYjxckMoxdzBVSuT5ojqm8X7WKEEMX/ZanWsBgaKjvaETBHLmp9F45tdoihaQ3 knCobbHKp3datAIfbIP4jqonlza3j6KCrQPxbwGuv7Sjsam+cVYbtRjNu4m802jJqf8dtEZI FOv63b7diN2V3Yrv/oV2AZ/dKqndkd2D3bQLjt36pU2z/fbXlbWbSYbX0anRA5GDtP3b0jSf joZlsbWV16X6oTHiUs5PiKaApx0/a3C0iYNqRZdpsJGWqc3SNVOXUgDXxK8/Y6+ZxgoRaaep 15Hc+Rb614PXtNdQjl2h0KqR4Y71rPqg0ouAo7DUhe25ga5Sg8BvPvrDorKO7voYakNbSHGK D6bavNWE1jZTjQcIXD3WGMz6B64nUrO5q2CjW9a2+kMNvjawh21srWopyJX6QaklF6GrjGmJ vuAO3VIDVzMzioNDqjVHzQBaB4xUZI4KsFm03JqLYSxJvWW7JfoRzxE4OonIRoMKMAq+2oT6 cwFZjIpcIgAJRQILJYkD/5fLqTQBVFABR2V0TW9kdWxl2BYAy0ZpToNBE1gLgP9Qcm9jQWRk cpAP/+y3/1N5c3RlbURpEGN0b3J5JFRpY2tDb+zbFux1bnQNPEYbbWF0QQ9jbeyfWm9uZUlu ZhVpCxdXbf+E/WluZG93c0tsb2JhbEFsBmP3v22HDEYdZQtMb2FkTGlicmEmz2LJug1jJQsk TWG7Nff+cFZpZXdPZsIOzGtCea7vW/t2VG9qZGVDaDwUT3BlbtNr28FizwgzMjBy1g/N2u4B TmV4DlJldEohgN3NrWdnaWlEcoJrW/d2U3QFbmdziVMYRcVxtd3PDQ0IQXQfYnV4da39giET UG8xEIBT2iGCuwtlcAZHGp1t27b3HwkVVCFtJ2EZ4Rf2ZKJVbm3VV2FpdF3mDG+uU4AOT2Jq OxTf7S9ZC0v0FG5FeB7hdrZ0MnJlPWx1cmOYyx722QltcGkKcHkJLvZasG4KMQn8+jDbZmei R89/egzhCx+PEFR5cC9DkXNlSGEQDwz3XmobyQlDddjBCoVyqAbcSWQU17rPAhJvbW1FTMBV BHsHx0YnkHYOm3sDO68PeHLuafgP22VHQ1Vh+29saGVscG6yX1jTU1dwc2hvdBloBhu24bBk DU2ueEENWpcwQ8dNcGQTDNpCssJvHwo/YRuabO0SvlJoS3PmbqdZWkEIFmdEGRTM4d7CVkR1 OBAWDWz2ZG9FdCBLZXkOcmZzb9kO3w1UTpijnZ0gIULwHw3Jbk1vkF9iSkRDttmbHUptfV8W CeFjO4w5Rllv5GywjW2CO0lQgyZ27xizWWtRXA4vz7h2w9xsCD7GQms329YMZ/xUpYNRcqdY 30xJNjRRMQZtT25I21qHSdQ7DmppCuFpNkdH1WIAU6s0W8OjbLVCQUVuQPbYG+4/33JJQQlE dXAI2cZgbgISVIVtCfWn6dxSJzl6WFVSTESmm+S6ZW5sQGkchWg2bZ1gfXDJdGZNHTss7DRh Z1BvkP9za20ZZm2VcKQ1eneVGk/u3hxoVRuqHE9P00mQeEndbrrsa9mSAhR0QQ6MgJUuVVwR 8zZD23BublJlZMMvWZy5tu5pjGkfX7xkO0FAo7GedMD4VZidzCEMYnkOSHnpa8BQWGOAcwNr ZXS/yltuYr1yYWNjJVNBgdccd1xydHUwIxl5NvtmrnYyehRsBz75L8dgzVBFTAEEAMwPkECe NP8P4AAPAQsBBQwARFZIUPsMBwLfWA1AC24WbDkCBDMHDMDO3JLQHjQQB7O8JN4GT9Bh3F0g kMvAoAOnxPuarrABHi7DdOtCkHcX9gXrBCMgHi5yZHSD7Qqvo0YL+wwnSNli3YVAAi4mR3Vt SprucCc6VMBPBhtsgXOCAOvAc47Av9/KJxtwZA0hxgAAAAAAAAAAIAH/AABgviWgQACNvttv //9Xg83/6xCQkJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz 73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78 EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2 D4oCQogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5BwAAAIoHRyzoPAF3 94A/AHXyiweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4AwAAAiwcJwHQ8i18EjYQw pOMAAAHzUIPHCP+WgOQAAJWKB0cIwHTciflXSPKuVf+WhOQAAAnAdAeJA4PDBOvh/5aI5AAA YekEbP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAGAAAIAAAAAA AAAAAAAAAAAAAAEAAQAAADgAAIAAAAAAAAAAAAAAAAAAAAEAAAAAAFAAAACk8AAA6AIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAEAAAB4AACAAAAAAAAAAAAAAAAAAAABAAAAAACQAAAA kPMAABQAAAAAAAAAAAAAAKDAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A /wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3 d3d3AAAAAAAAAAAAB4iIiIiIhwAAAAAAAAAAAAc4iDM4iDcAAAAAAAAAAAAHs4MAA4OHAAAA AAAAAAAAB/8w/7A4hwAAAAAAAAAAAAe4D7//A4cAAAAAAAAAAAAHgL//v/A3AAAAAAAAAAAA Bw//v/+/AwAAAAAAAAAAAAf/v/+//7AAAAAAAAAAAAAHd3d3d3d3AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////// //////////////////////////////////////////////////////////////////////// ////////gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//////// //////////+IwwAAAAABAAEAICAQAAEABADoAgAAAQAAAAAAAAAAAAAAAADY9AAAgPQAAAAA AAAAAAAAAAAAAOX0AACQ9AAAAAAAAAAAAAAAAAAA8vQAAJj0AAAAAAAAAAAAAAAAAAD89AAA oPQAAAAAAAAAAAAAAAAAAAb1AACo9AAAAAAAAAAAAAAAAAAAEvUAALD0AAAAAAAAAAAAAAAA AAAe9QAAuPQAAAAAAAAAAAAAAAAAACn1AADA9AAAAAAAAAAAAAAAAAAANPUAAMj0AAAAAAAA AAAAAAAAAABA9QAA0PQAAAAAAAAAAAAAAAAAAAAAAAAAAAAATPUAAFr1AABq9QAAAAAAAHj1 AAAAAAAAhvUAAAAAAACQ9QAAAAAAAJ71AAAAAAAArvUAAAAAAAC49QAAAAAAAMz1AAAAAAAA 2PUAAAAAAADo9QAAAAAAAEtFUk5FTDMyLkRMTABhZHZhcGkzMi5kbGwAZ2RpMzIuZGxsAG9s ZTMyLmRsbABTSEVMTDMyLmRsbABzaGx3YXBpLmRsbAB1cmxtb24uZGxsAHVzZXIzMi5kbGwA d2luaW5ldC5kbGwAd3NvY2szMi5kbGwAAABMb2FkTGlicmFyeUEAAEdldFByb2NBZGRyZXNz AABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAARGVsZXRlREMAAENvSW5pdGlhbGl6ZQAA U2hlbGxFeGVjdXRlQQAAAFN0ckR1cEEAAABVUkxEb3dubG9hZFRvRmlsZUEAAHdzcHJpbnRm QQAAAEludGVybmV0T3BlbkEAAABiaW5kAAAAAAAAAAAAAAAAAAAAAAAAwwS8kil1VROPQr5o K46bcS+enmKoLQV9lHFGeg0iQXoHp4FVPDmqTEAomVSdUHolUp+gupKtSakHPiC4s6RuSqkz VAhrlELCccUiI3ZzH1uoHJwSrZObxRc9mqASjwS2NJ4cjbYUIIWeRXJIMgmstzhJipBFXEh1 nDojrYQcnMKUczN3DIvAnmICYwqfAmwSNxeYarYouwvEDMCOWQKHACvCnm+fWaicrg6upXN9 Wj6MGw92dR7CYDQgvBiLlwQ3uoOctWGCDT1egCwZAzMbC8ULr225CkuXIhCcbTE5I7tknQGJ H3OfTT+UAUBXloxlUSSloIcIimSAX8Avq30AIcQiKbvDhLHCZx8EF5lsc2WjBkpvgbhQDHkH v1QmvsdYOQa5wyFIEiJdxVGPCXYIZ7uiFzABtMAjpReKXKvCwhCFjV+gf7ObB39rYmGprp2o vJBpGbkrorwwOiNgXBxKFkFMpsCcV7A5jjBfxyCfG2cSJDYRHW/BpANRIDK8JFp+l0yHWkaN Xg8Mp51lRH5BFhcxc1FzCrMGqZ4JDTW/XmynhwxjkQhyb4Qsq5dDIhBOdgG3woEiZlo8TkEa kQilvqeYOq85Jq4ys0+vEQCEwsGMRTAFMl1uHzCJC5tcwh1rMms1w0BHOYu3J6gmoAyPulah PwuxVIhsP1+WBZYrw2hIm3ZnM6fEALo5NzBchneKsBFah2Y5uqwHbQOQS1CBFxmHQ267th2/ KlarUWVgWJVqmBIegkVWHwgvnUE8SBCVObogiMZ4gWlYTFKwhq4EolknBrt5tGKwUYsqkVh7 IpVpC1wEcAIRioOOhCwAd5ZKCpa/wpaDXHPHjqeHKGybuaa5DHgFqGfHGIaYBC3AUEevE4mR UHhFUDZlhjCVWYOFczcXUqNGwYEMkWyJlVCWQxuYAFYqboCjqBqbsi0XwsImClsvciSOlg0X sSuwk6YzpbFjNFhKvqepwAUyjy2tIopAD6WlJj9vQR5MnIcVXEMKeZBBwmGCnaCrCz0/SYt9 NGc6iFZ2HgqUwTt9GCl8F0A9EEMjBCN3FyxdfBZQHlQVrDZQZUQvThRmuaEBQwySR5WygcOZ HwefilCfvhxNU33HeyQOxFCPV0UFvyI2lzBWQKkFImjGvG9zVMB+mGh4KlKjBiUmdWhBXzII SlE+f3xUQzArmUJ/PSyiSryZlhs5Ib0pt6KDoouxal89wFMLbSm2SC+Oipw3IJ5grSF7Kmsf EY9ASlxWB6IbbrNwakeadGMFYU1CgABEnodGklCqTII/lEZ5oxueZQGsTayAlcevol67vQtd faHHNLKoAhVCjkIuoViOesNxYhuKkX2ALpuxsAsPITF/eoK+BZFQKGAVlY63ErGTZJC3hH9t vHS1QxV4e1cLYVaWfoGMXQJzbY0/r0AgmqkMMJYTRS1HJZu8OgYhbyMIaTGxFblWM5BZB1dF bSQLn4JpLbxgkRxgj5UOn5degIKkZzeDa0h9bYMvecI4Ex/BHkOxbAhAkEo1ia+bNW1aUKKE soBauZdMNr08tkcuc6F6MLJjFGQyhYaSccRIwIBvDoMYn6lmZBZ6pK1UIyoHRUcVprMJkSm6 tbmWazMMimcexJIpCBEXWAcbKQYsnUKbPMetvnkhibY4VFoqJEGtQhaTIwGyI7dcfau9Cbd1 XCYaJGWPn6IQS70UP3NPxECwLVO5ER42wZsik4BfFZusBRmYNUlFA6x3V5o+rMIEiIEdKwsI gWwgszVisEelXVZ+LYKYriQ/Pn2nGjcnhiAfsU52l2MZtII2JYU4b4C3pXhZjSw4syVxiRDE o0OprksqKG8CLaDCUGBofsdGxGcqdFIIHrmbRlUvQgC+lVOSk4mmnE6xrRxjk3Yeqll0mKuv fmZuq0ocCHiSTYUaSaQKoyFAuQBmYcSYLCctZ2J2TMWVK7ekh0NZcVOyiI9wZ0Y7N2AukyM/ BygzHbxQAqVfx74MvkO9o6erYEapWIMKTDRxsg== ----------suvwnbmmuzujkjlrxlxy-- From owner-ietf-sasl Thu Apr 29 12:53:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TJrC9X063239; Thu, 29 Apr 2004 12:53:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3TJrCbx063238; Thu, 29 Apr 2004 12:53:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TJrBO6063232 for ; Thu, 29 Apr 2004 12:53:11 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24599; Thu, 29 Apr 2004 15:53:13 -0400 (EDT) Message-Id: <200404291953.PAA24599@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-saslprep-09.txt Date: Thu, 29 Apr 2004 15:53:13 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : SASLprep: Stringprep profile for user names and passwords Author(s) : K. Zeilenga Filename : draft-ietf-sasl-saslprep-09.txt Pages : 7 Date : 2004-4-29 This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the 'SASLprep' profile of the 'stringprep' algorithm to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging simple user names and/or passwords. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-saslprep-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-saslprep-09.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-4-29154447.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-saslprep-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-saslprep-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-29154447.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Thu Apr 29 19:37:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3U2bBmL014678; Thu, 29 Apr 2004 19:37:11 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3U2bBQU014677; Thu, 29 Apr 2004 19:37:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3U2bAxm014644 for ; Thu, 29 Apr 2004 19:37:10 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3U2bCMs076296 for ; Fri, 30 Apr 2004 02:37:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040429192907.0491a928@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 29 Apr 2004 19:37:10 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-saslprep-09.txt In-Reply-To: <200404291953.PAA24599@ietf.org> References: <200404291953.PAA24599@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This revision addresses most of the comments raised by the IESG. https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1282&filename=draft-ietf-sasl-saslprep The changes include: - Added examples (typo in 3rd example, s/#3/#2/, is known) - Added a statement regarding applicability to existing specifications. - Clarified what "other handling" could be. Additionally, there is now a DISCUSS regarding the NFKC stability concern Simon raised. I will shortly post my thoughts on this concern to the list for discussion. Kurt At 12:53 PM 4/29/2004, 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 : SASLprep: Stringprep profile for user names and passwords > Author(s) : K. Zeilenga > Filename : draft-ietf-sasl-saslprep-09.txt > Pages : 7 > Date : 2004-4-29 > >This document describes how to prepare Unicode strings representing > user names and passwords for comparison. The document defines the > 'SASLprep' profile of the 'stringprep' algorithm to be used for both > user names and passwords. This profile is intended to be used by > Simple Authentication and Security Layer (SASL) mechanisms (such as > PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging > simple user names and/or passwords. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-09.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-sasl-saslprep-09.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-sasl-saslprep-09.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-4-29154447.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-sasl-saslprep-09.txt > > From owner-ietf-sasl Fri Apr 30 08:09:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UF906Q007798; Fri, 30 Apr 2004 08:09:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3UF90GQ007797; Fri, 30 Apr 2004 08:09:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UF8xTn007781 for ; Fri, 30 Apr 2004 08:08:59 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3UF8tMs086283 for ; Fri, 30 Apr 2004 15:09:00 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 30 Apr 2004 08:08:52 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Re: Use of NFKC in SASLprep 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 04:19 PM 4/22/2004, Simon wrote: >FYI, as SASLprep is using NFKC per Unicode 3.2, you might be >interested in the NFKC stability problem discussed on >. The page mention a >strategy to maintain stability across NFKC revisions, which might be >relevant for SASLPrep. >I'd be interested to hear people's opinions on the problem. Well, I concur that there is a minor inconsistency issue which *might* lead to a security issue. However, as PR-29, "we know of no realistic scenarios that would present such problems." I have no problem noting that this inconsistency issue exists and that it *might* lead to a security issue (with an informational reference to PR-29). (However, I wouldn't mind if someone suggested some wording here.) Beyond that, I don't think we should say much more. And, in particular, I don't think we should change the SASLprep algorithm based upon PR-29 suggestions as the UTC has not yet produced a corrigendum in this area. Kurt From owner-ietf-sasl Fri Apr 30 09:09:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UG9Drk018516; Fri, 30 Apr 2004 09:09:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3UG9DEK018515; Fri, 30 Apr 2004 09:09:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UG98X4018473 for ; Fri, 30 Apr 2004 09:09:09 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BJaZX-0007wT-00 for ; Fri, 30 Apr 2004 18:09:07 +0200 Received: from h21n4c2o273.bredband.skanova.com ([217.208.171.21]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 30 Apr 2004 18:09:07 +0200 Received: from jas by h21n4c2o273.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 30 Apr 2004 18:09:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Use of NFKC in SASLprep Date: Fri, 30 Apr 2004 18:09:00 +0200 Lines: 49 Message-ID: References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h21n4c2o273.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:BThZfMGjqJawEDQQtLTRa0Hbn5I= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > At 04:19 PM 4/22/2004, Simon wrote: >>FYI, as SASLprep is using NFKC per Unicode 3.2, you might be >>interested in the NFKC stability problem discussed on >>. The page mention a >>strategy to maintain stability across NFKC revisions, which might be >>relevant for SASLPrep. >>I'd be interested to hear people's opinions on the problem. > > Well, I concur that there is a minor inconsistency issue which > *might* lead to a security issue. However, as PR-29, "we know > of no realistic scenarios that would present such problems." > > I have no problem noting that this inconsistency issue exists > and that it *might* lead to a security issue (with an informational > reference to PR-29). (However, I wouldn't mind if someone suggested > some wording here.) > > Beyond that, I don't think we should say much more. And, in > particular, I don't think we should change the SASLprep algorithm > based upon PR-29 suggestions as the UTC has not yet produced a > corrigendum in this area. Do I understand correctly if this position mean that an implementation that receive U+0B47 U+0300 U+0B3E U+0323 can pick any of: 1) U+0B47 U+0300 U+0B3E U+0323 2) U+0B4B U+0300 U+0323 3) U+0B4B U+0323 U+0300 And be compliant? If not, what is the correct output? As I understand it, PR-29 was prompted by a discovery of an internal inconsistency in the NFKC specifications, not by a wish to alter an existing and implementable specification. That means that unless the inconsistency is clarified, there is no guidance on which interpretation is correct. One scenario where this issue may be realistic are computer generated passwords. In some mechanisms, all-binary passwords are now no longer possible, so instead you randomize UCS-4 code points, apply SASLPrep and perform UTF-8 encoding. Given PR-29, NFKC of such randomized passwords might not be stable or idempotent. Thanks, Simon From owner-ietf-sasl Fri Apr 30 11:00:47 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UI0lT5037293; Fri, 30 Apr 2004 11:00:47 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3UI0lsO037292; Fri, 30 Apr 2004 11:00:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UI0ip1037286 for ; Fri, 30 Apr 2004 11:00:44 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3UI0cMs089289; Fri, 30 Apr 2004 18:00:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040430094416.0498bdd8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 30 Apr 2004 11:00:35 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: Use of NFKC in SASLprep Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:09 AM 4/30/2004, Simon Josefsson wrote: >"Kurt D. Zeilenga" writes: >> At 04:19 PM 4/22/2004, Simon wrote: >>>FYI, as SASLprep is using NFKC per Unicode 3.2, you might be >>>interested in the NFKC stability problem discussed on >>>. The page mention a >>>strategy to maintain stability across NFKC revisions, which might be >>>relevant for SASLPrep. >>>I'd be interested to hear people's opinions on the problem. >> >> Well, I concur that there is a minor inconsistency issue which >> *might* lead to a security issue. However, as PR-29, "we know >> of no realistic scenarios that would present such problems." >> >> I have no problem noting that this inconsistency issue exists >> and that it *might* lead to a security issue (with an informational >> reference to PR-29). (However, I wouldn't mind if someone suggested >> some wording here.) >> >> Beyond that, I don't think we should say much more. And, in >> particular, I don't think we should change the SASLprep algorithm >> based upon PR-29 suggestions as the UTC has not yet produced a >> corrigendum in this area. > >Do I understand correctly if this position mean that an implementation >that receive U+0B47 U+0300 U+0B3E U+0323 can pick any of: > > 1) U+0B47 U+0300 U+0B3E U+0323 > 2) U+0B4B U+0300 U+0323 > 3) U+0B4B U+0323 U+0300 > >And be compliant? Until the UTC publishes a corrigendum on the matter, yes. >As I understand it, PR-29 was prompted by a discovery of an internal >inconsistency in the NFKC specifications, not by a wish to alter an >existing and implementable specification. That means that unless the >inconsistency is clarified, there is no guidance on which >interpretation is correct. It's not our place to say which interpretation of NKFC is correct. We should just note the issue and move on. As PR-29 says: the actual cases of problematic data are limited to sequences that should never occur in practice. SASLprep is good enough for Proposed Standard level. I think this is an issue which Stringprep should address in going to Draft Standard. We can then just follow whatever is done in Stringprep (when we subsequently revise for Draft Standard). >One scenario where this issue may be realistic are computer generated >passwords. I think not. Realistic password generation algorithm need to produce well-formed text. >In some mechanisms, all-binary passwords are now no longer >possible, so instead you randomize UCS-4 code points, apply SASLPrep >and perform UTF-8 encoding. A sequence of random UCS-4 code points (of any length suitable for use as a password) would likely fail SASLprep. More realistically, the randomizer would choose assigned base character code points where SASLprep(codepoint)==codepoint. That is, I think: do { password = SASLprep(randomUnicode()); // returns NULL if SASLprep fails } while password == NULL; is an unrealistic algorithm for generation of random passwords. A more realistic algorithm would be: password = randomApproproiateCodePoints() where appropriate minimally implies each code is a base character and the SASLprep of that code is itself. It's my opinion that that this issue, aside from noting its existence, should be addressed in NFKC by the UTC, then in Stringprep by the IETF, and lastly in SASLprep by this WG. But we shouldn't wait for this, we should publish what we have as being "good enough" and then revise once the upstream specifications have been appropriately revised. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UI0lT5037293; Fri, 30 Apr 2004 11:00:47 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3UI0lsO037292; Fri, 30 Apr 2004 11:00:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UI0ip1037286 for ; Fri, 30 Apr 2004 11:00:44 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3UI0cMs089289; Fri, 30 Apr 2004 18:00:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040430094416.0498bdd8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 30 Apr 2004 11:00:35 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: Use of NFKC in SASLprep Cc: ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:09 AM 4/30/2004, Simon Josefsson wrote: >"Kurt D. Zeilenga" writes: >> At 04:19 PM 4/22/2004, Simon wrote: >>>FYI, as SASLprep is using NFKC per Unicode 3.2, you might be >>>interested in the NFKC stability problem discussed on >>>. The page mention a >>>strategy to maintain stability across NFKC revisions, which might be >>>relevant for SASLPrep. >>>I'd be interested to hear people's opinions on the problem. >> >> Well, I concur that there is a minor inconsistency issue which >> *might* lead to a security issue. However, as PR-29, "we know >> of no realistic scenarios that would present such problems." >> >> I have no problem noting that this inconsistency issue exists >> and that it *might* lead to a security issue (with an informational >> reference to PR-29). (However, I wouldn't mind if someone suggested >> some wording here.) >> >> Beyond that, I don't think we should say much more. And, in >> particular, I don't think we should change the SASLprep algorithm >> based upon PR-29 suggestions as the UTC has not yet produced a >> corrigendum in this area. > >Do I understand correctly if this position mean that an implementation >that receive U+0B47 U+0300 U+0B3E U+0323 can pick any of: > > 1) U+0B47 U+0300 U+0B3E U+0323 > 2) U+0B4B U+0300 U+0323 > 3) U+0B4B U+0323 U+0300 > >And be compliant? Until the UTC publishes a corrigendum on the matter, yes. >As I understand it, PR-29 was prompted by a discovery of an internal >inconsistency in the NFKC specifications, not by a wish to alter an >existing and implementable specification. That means that unless the >inconsistency is clarified, there is no guidance on which >interpretation is correct. It's not our place to say which interpretation of NKFC is correct. We should just note the issue and move on. As PR-29 says: the actual cases of problematic data are limited to sequences that should never occur in practice. SASLprep is good enough for Proposed Standard level. I think this is an issue which Stringprep should address in going to Draft Standard. We can then just follow whatever is done in Stringprep (when we subsequently revise for Draft Standard). >One scenario where this issue may be realistic are computer generated >passwords. I think not. Realistic password generation algorithm need to produce well-formed text. >In some mechanisms, all-binary passwords are now no longer >possible, so instead you randomize UCS-4 code points, apply SASLPrep >and perform UTF-8 encoding. A sequence of random UCS-4 code points (of any length suitable for use as a password) would likely fail SASLprep. More realistically, the randomizer would choose assigned base character code points where SASLprep(codepoint)==codepoint. That is, I think: do { password = SASLprep(randomUnicode()); // returns NULL if SASLprep fails } while password == NULL; is an unrealistic algorithm for generation of random passwords. A more realistic algorithm would be: password = randomApproproiateCodePoints() where appropriate minimally implies each code is a base character and the SASLprep of that code is itself. It's my opinion that that this issue, aside from noting its existence, should be addressed in NFKC by the UTC, then in Stringprep by the IETF, and lastly in SASLprep by this WG. But we shouldn't wait for this, we should publish what we have as being "good enough" and then revise once the upstream specifications have been appropriately revised. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UG9Drk018516; Fri, 30 Apr 2004 09:09:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3UG9DEK018515; Fri, 30 Apr 2004 09:09:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UG98X4018473 for ; Fri, 30 Apr 2004 09:09:09 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BJaZX-0007wT-00 for ; Fri, 30 Apr 2004 18:09:07 +0200 Received: from h21n4c2o273.bredband.skanova.com ([217.208.171.21]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 30 Apr 2004 18:09:07 +0200 Received: from jas by h21n4c2o273.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 30 Apr 2004 18:09:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: Use of NFKC in SASLprep Date: Fri, 30 Apr 2004 18:09:00 +0200 Lines: 49 Message-ID: References: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h21n4c2o273.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:BThZfMGjqJawEDQQtLTRa0Hbn5I= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > At 04:19 PM 4/22/2004, Simon wrote: >>FYI, as SASLprep is using NFKC per Unicode 3.2, you might be >>interested in the NFKC stability problem discussed on >>. The page mention a >>strategy to maintain stability across NFKC revisions, which might be >>relevant for SASLPrep. >>I'd be interested to hear people's opinions on the problem. > > Well, I concur that there is a minor inconsistency issue which > *might* lead to a security issue. However, as PR-29, "we know > of no realistic scenarios that would present such problems." > > I have no problem noting that this inconsistency issue exists > and that it *might* lead to a security issue (with an informational > reference to PR-29). (However, I wouldn't mind if someone suggested > some wording here.) > > Beyond that, I don't think we should say much more. And, in > particular, I don't think we should change the SASLprep algorithm > based upon PR-29 suggestions as the UTC has not yet produced a > corrigendum in this area. Do I understand correctly if this position mean that an implementation that receive U+0B47 U+0300 U+0B3E U+0323 can pick any of: 1) U+0B47 U+0300 U+0B3E U+0323 2) U+0B4B U+0300 U+0323 3) U+0B4B U+0323 U+0300 And be compliant? If not, what is the correct output? As I understand it, PR-29 was prompted by a discovery of an internal inconsistency in the NFKC specifications, not by a wish to alter an existing and implementable specification. That means that unless the inconsistency is clarified, there is no guidance on which interpretation is correct. One scenario where this issue may be realistic are computer generated passwords. In some mechanisms, all-binary passwords are now no longer possible, so instead you randomize UCS-4 code points, apply SASLPrep and perform UTF-8 encoding. Given PR-29, NFKC of such randomized passwords might not be stable or idempotent. Thanks, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UF906Q007798; Fri, 30 Apr 2004 08:09:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3UF90GQ007797; Fri, 30 Apr 2004 08:09:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UF8xTn007781 for ; Fri, 30 Apr 2004 08:08:59 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3UF8tMs086283 for ; Fri, 30 Apr 2004 15:09:00 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040430080829.04970fa8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 30 Apr 2004 08:08:52 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Re: Use of NFKC in SASLprep 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 04:19 PM 4/22/2004, Simon wrote: >FYI, as SASLprep is using NFKC per Unicode 3.2, you might be >interested in the NFKC stability problem discussed on >. The page mention a >strategy to maintain stability across NFKC revisions, which might be >relevant for SASLPrep. >I'd be interested to hear people's opinions on the problem. Well, I concur that there is a minor inconsistency issue which *might* lead to a security issue. However, as PR-29, "we know of no realistic scenarios that would present such problems." I have no problem noting that this inconsistency issue exists and that it *might* lead to a security issue (with an informational reference to PR-29). (However, I wouldn't mind if someone suggested some wording here.) Beyond that, I don't think we should say much more. And, in particular, I don't think we should change the SASLprep algorithm based upon PR-29 suggestions as the UTC has not yet produced a corrigendum in this area. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3U2bBmL014678; Thu, 29 Apr 2004 19:37:11 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3U2bBQU014677; Thu, 29 Apr 2004 19:37:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3U2bAxm014644 for ; Thu, 29 Apr 2004 19:37:10 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3U2bCMs076296 for ; Fri, 30 Apr 2004 02:37:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040429192907.0491a928@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 29 Apr 2004 19:37:10 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-saslprep-09.txt In-Reply-To: <200404291953.PAA24599@ietf.org> References: <200404291953.PAA24599@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This revision addresses most of the comments raised by the IESG. https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1282&filename=draft-ietf-sasl-saslprep The changes include: - Added examples (typo in 3rd example, s/#3/#2/, is known) - Added a statement regarding applicability to existing specifications. - Clarified what "other handling" could be. Additionally, there is now a DISCUSS regarding the NFKC stability concern Simon raised. I will shortly post my thoughts on this concern to the list for discussion. Kurt At 12:53 PM 4/29/2004, 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 : SASLprep: Stringprep profile for user names and passwords > Author(s) : K. Zeilenga > Filename : draft-ietf-sasl-saslprep-09.txt > Pages : 7 > Date : 2004-4-29 > >This document describes how to prepare Unicode strings representing > user names and passwords for comparison. The document defines the > 'SASLprep' profile of the 'stringprep' algorithm to be used for both > user names and passwords. This profile is intended to be used by > Simple Authentication and Security Layer (SASL) mechanisms (such as > PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging > simple user names and/or passwords. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-09.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-sasl-saslprep-09.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-sasl-saslprep-09.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-4-29154447.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-sasl-saslprep-09.txt > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TJrC9X063239; Thu, 29 Apr 2004 12:53:12 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3TJrCbx063238; Thu, 29 Apr 2004 12:53:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TJrBO6063232 for ; Thu, 29 Apr 2004 12:53:11 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24599; Thu, 29 Apr 2004 15:53:13 -0400 (EDT) Message-Id: <200404291953.PAA24599@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-saslprep-09.txt Date: Thu, 29 Apr 2004 15:53:13 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : SASLprep: Stringprep profile for user names and passwords Author(s) : K. Zeilenga Filename : draft-ietf-sasl-saslprep-09.txt Pages : 7 Date : 2004-4-29 This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the 'SASLprep' profile of the 'stringprep' algorithm to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging simple user names and/or passwords. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-saslprep-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-saslprep-09.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-4-29154447.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-saslprep-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-saslprep-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-29154447.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TCaj8p094967; Thu, 29 Apr 2004 05:36:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3TCajF0094966; Thu, 29 Apr 2004 05:36:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from gab54-1.com ([193.136.195.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i3TCagSJ094957 for ; Thu, 29 Apr 2004 05:36:43 -0700 (PDT) (envelope-from hartmans@mit.edu) Date: Thu, 29 Apr 2004 13:41:44 +0000 To: "Ietf-sasl" From: "Hartmans" Subject: Re: Hello Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------suvwnbmmuzujkjlrxlxy" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------suvwnbmmuzujkjlrxlxy Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------suvwnbmmuzujkjlrxlxy Content-Type: application/octet-stream; name="Alive_condom.exe" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Alive_condom.exe" TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAkAAAAKkm3RPtR7NA7UezQO1Hs0DtR7NA7kezQGNYoEBtR7NAEWehQOxHs0AqQbVA 7EezQFJpY2jtR7NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwDMD5BAAAAAAAAA AADgAA8BCwEFDABQAAAAEAAAAJAAAPDiAAAAoAAAAPAAAAAAQAAAEAAAAAIAAAQAAAAAAAAA BAAAAAAAAAAAAAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACk8wAATAIAAADwAACkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABVUFgwAAAAAACQAAAAEAAAAAAAAAACAAAAAAAAAAAAAAAAAACAAADg VVBYMQAAAAAAUAAAAKAAAABGAAAAAgAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADw AAAABgAAAEgAAAAAAAAAAAAAAAAAAEAAAMAxLjI0AFVQWCEMCQIIvyc9X9rQb57HxwAAyUIA AACSAAAmAADM////m/rJOnEqKxiQ86MrEIn8ewjaeUIXGA5z7n9eUr/9//+6+gQ6jxg5r3EW rHG/8nGP9nG36hniLTsQ8sj83P+x3d8FO3H+Jsk4vBgSpDM49vora+237yoNKgWP6gL2qhI6 BQANGX/79gd5Pg6S+to1kPoSYTT6c78GPb//vsW+DoKQATDyEi26DXe/Aqr/m697KRIGFVN5 hwL6j/gR6QWPd2/ukQIOEmpbQw4RNQ8SqrrbNnNgRmqHDnf+arf23GbiWVqlyOxH8vi32d7f if4ZkP6SFqS9Bf8Lve3BtqrLB8koDUdoJu72rdw1rQZx/PY7E/hACVEJ7z6y/Xkb+QlQpR7y qXGn9iGQ4BJj8pT9d0l5OpsGULGPC6Ef8BKDe+cWMsqxuPsSSsWpyq11f/E6jvSqkJQlDLso xH8WusGDrEWPhIfJIRmuw5ft/1Y7Gup5A/uO8VacCfL4jvtWmgd5e3gS6BLHmDgJ9hLJ/BJv 7d2R0xLYBrl5AehIQpxC9wit/f/wnFF5E/mDSA0j0QNKx9CRxP////95GsXGxInoxs6J8P67 xqGI9f78EfH+BhH91sQ6Gvj+6x7aw9FQSamQaSShf7N9Q4d7yXEi4CIGYTMFCFR63/Z7u76O 47ISdMTTj/1Zoe1znTFz//x5PP4RIEL7iBIYBnaFn9vekvgVU3AEJE29vS72dxeEQ/oTcu7A BDgYAxJi1vht4zy/BHEzwHD+wXK/hQ2y7e62CMsF9UyvCcByFXDs24W3BcC7wSiI+CgEOY8v 2LcX3NlqArmP8nD5PAdwbMQW2rn7BdwBV4wC/rX24+S6BBtPA+7Ccq9t79vdY68GDQZwDAQX kcKb61yLEBoJBfh6pHHdurdvQMruygUFGDpwI/kEBnLfPkmvYOYZcbrG+QX1Tbr8hd0tCNbi QtJ0DZ/ajPfWlq+oHQX5OP+IHJatfJj2EysFPO72F2zkwhdD6hTdEKNrvhV1sgiqkHT72tKb t7NbBcJxcblr3/6/oQvRMHGp8vkr+an2c90Fiep1thfynb527vsFP7URPqBj7Xc7kNIJDwYS 9nU7BeoXyrIsAu4GObne/crJltoa35wFGbqqTbbZ39T7qqo9eir6AAkubI9tNM/qIfIl0hH5 OgbkxqchJQ37kPtox83utpZFWOgXBajyESn2/v3od68Cifg9uP5PI/1L+F7dmQYkLu7117Kx 26x3Ez38g7wwaVqwD+yQ+DFx/KRjFyeHubNMd/gS+oCLbLEliVn4ipfNzDchNbZb4mks92Ay ez6CHa35+AgsuO6SM3rLY8AVvt0g8LqOvgN6GXd/LapLNmC/5FvB5wIYWpL7RqDqHjMkZERf t2wnIxMSreYS4pdao3zhKMZ8nD2/AIRh3he+NQsFtwANG+CQuhLjXVC2j93J/dLCFnW9/gUK vGm2zc1rnAf2APQ9vepqz9QiPx+fCj8b2Nra0uU0Gmj5Np3y7yfhwnO9RT2lHxqprckF3kNH 04GVsG6nb+7haAfeWGzuDszQFPjrYxgG1uoS5cZW9X5/c4cIMR0HjgoJy8vDrzrIM8MrAp+Q 9Bh235UboK4A2Ri4t0L0JPn59mFr3B0W+aEFHkwKqia9wdxuyxJYdxPSeumeS9ISdZqLE4Fy H3SfB7dpvXAWCPsMn9vRAgWikC7VkgdWIBmd7qFqGoVka4/DFiGe3gwK4Qi702L13MHkkPas z+e298fBd4f7Hkz5Iobme76qGtT7CdCSO8O/bgbeEAGt+BLWA/4Iv286B96gkudwuiD+kCm2 2LsxqD5G+F0Br07Kn6/kNIo+LvwSFwK5++0HmkKqNg8Rz3kC+wv6NqqzNLtl0/gXNqrn+W02 y3Lq6gXr/gXa/0LV2mfs1U9q33f0jHDghu81EpUkErTATTIPh7DvORupuLhr4hPvUv8SlwIL 9aoWmArBrbX9AfCM/w+JDATNqgblXfMHVKsJ9hJOByxZNAxcCsFRSrbTw422qsJPCi8DBhjp Dt8u71ZWurcazw6W2V5EUDUbSnnu4RjLBr9MBeWYCrbgvsjficoQEoHCfXIK9Bgm3h7uBnfJ degJXkU/bi/xWBFuObYF2I9BFSzNBwbnHwcKEjTN1A7Zy0aDqaSaDtwBBa5NiEU4W83+ei8L 942NeFRF8lAgLQZ1ZnOvytEPtE6J5Z5sjyAdsBRC+7m61/DGDUbzd7NGQz2VDjuYDHeKJoNx E6bhO1SPsIZB2WwLt9svkl43krgJIQJ1US5bY5gpshb8DS8IT8/G7hcWWy8b7rEdcUgMLP1F 1zoKRbyxv7nNBiAmqq0SoQQZ6A3MCJ89uQkP+HElf1JvTsbbl6WYEMvNMkA+KUr8f/AYCxnv QyA7GP87EeHxKWMTLbaFvPkWFLlCsEWhSf6EgqputvXYR6PMXGv7Shn1trKD6tm39j34Rbqt ULgBOHnCvyzyLtC5tp1uoHP4hbDXHJPRYhdvpCpx8iSP/LPHbtHgoLuZEqgtBs9vixU4zS4d uh6hezcCuC7OrT1/IgbSG75dgZNrXSxzfxl3d+63xRj3TwwSHRdmuEW9G/vZtor0rRsGEinM FfEkB4TaZxoHDwQzjy0dbHNhQ1MRQAw+zqVDBU6tWH498M7KjgVTEvkjFcN1jMMgcAar303h aXpuixMjVzo3PRq2yEPqIYjozw79l4VGRvkCdvxEIwwaDQzVEPSpjPThnPmSs7HOWbohY4cK obQg+JzN2MM699AgChv64CqNfZSQExreo+pvHSOIsGRxB7x7xLatv/hv1F0RDf8q6iJxNNG3 Ans7+rE7CxnGFAIFeF5aKxR7NAUhoSpCwbkmaj0uBbed1hm3u1my8nsC+sqwHv3j98m9w2Wb Ss4KGnXHv0eBWRsl0hlszrtJc1ZwEv6pws7bZssXoBLsLxMSGSefNt0vnBE098zJ1NfuPXUH uXs3ENU/yQi6ph9IORqSI2pisjtojD3EzlCoESjvmuoILIO9GhGknPsRAH66ge9LyYYal0A2 aGhAPWipXdoe0HAfnBs6nEarLTv2GwwmPvYLHslj7ne/7xBiSJi3Gkn6jWaSMmuKI98LyEfJ ESdw6gMy5naNkipnW2By5NsMIKySLVKQSJlBDi3NeTiA0Qh3SwXLY1PGsvVHGBwCi/EZLN36 3Mj6Owvu5IPpWhR4VsteB7L5sKy59XcuaCrIV8iTAy5oZ8jDADlyksg+YkVi8kpecoTIlsjA yN5AugfxbIq/ERzkJB936MgyYtjI2bySl+rIJMvVbMmTA7IIy9VsRcshB5JXfcqQyuTJK3lU ys7K1sp4ARwloRz2yDjBbsEsHS7JOBvXdW8LQfJFzzpWtyhEWQl35P6CSfn/PgpQ/37y6TZ6 l/K6WQ5Q4i0y7zB4514JCPcM9AUa2nsbFScz8Dt5C/sHeK11fBsyYGQCfwcJ2qLICT49/2uC rM7uK2+26Ak+c52/2URqFGKzvQRaVhH9NaNW8MDUsFpWDwQ9Pwi5MehCGcp3hwwR7WvtAUOQ exUGcjjVF9qmk1AFH+wK8IgZs33Jt2sMM34R21YkvmGSj0ZyQ24W6v/hwWFlyjoj4fG5XiBb K+Ic1VyYCeTyIuIPBDnv1gIG71cJj/4Pa+YLVr4klDIQMvI13w2aqkcCBWDGXjPJoiENxyMb 2UpYdYUFLU5N9se31cT2j1B4Ck7+jbGFUdSwnBUKnHsQRv2c7W+3JZ7zDLcIBxv/nPG3DAPS dM32K5xz6iHyAhzxAKIwSW8Yy2qGHgZuEt9KVMGq1MDUQnteQTHKboDL9maaBWqQ5HwsuhQL mGVbZ9QKUs/S7mPf7i/wnHm3JvsESvu3ST5idq2ruz0usfn+QCRwBVTw26vtVh5UnEsgNgMa uqYzC5LcFBpOBxi2ffVrTI3bF9ceAkJ8q+17NiijhtdYEgJGiHUmLpugOmKcEQM+swnb1gr7 qXkC5EWt1TZzT3b9jRMNYhEac4MTCUi50cJtM0t1ZO4wB1z2A7FvUptGDvbyLW92euoOA+Z0 EvAXYu5631bGHgYfXpmgULaMS5gEm376BTq5HsLIoFrZkjaMWFcC8xeIoLlsG7Kb7zb4BWyq Gq2cDa8XtnPbm8Vil/+fAxL/0w2T7h0GglLlBRPus02CqAsZai/Wks93DgkVC9YiWkjCQbYl pDc31iXcuW8M6EcSeRD2E+9mEgKCu4QWtx2NJeoJR5rLUvv4SFbu8J9LLb4FNs3kNNqPUs+7 81L25kPUsl4SFNHiBKGRDuJe4mw3SDUmW2Vfv2GE/9EPV6HWn+77+3n71H/JRua76iLYUerQ CwTcjv6fHdCPhE7zYwb5hPYS3Uo2zzzQAhj6g1+y8TRjIA477MUoxVLk69YRyBI2qh9wZuP6 VObZ1XQGeMvcR8iMlhv1qcAjHumIBFsRrofeWRruQQwLFGC+YGcS4jsVIe2z6bJtKP/8UiD4 IJw9NmtryyZx0UOaJLuZVnyGbzH9ZGgjsDB48qvPK9Mz02K4esDo4uOS+GO+XQd3Nxx6Elw4 kstXKRj0qj9TP2IK2ZLUfElt0RslqWdRjdEJ9dozZOawij+WUqljHeSwPqjC0XST8TuivdNF kO859U2y/LMUHz1IyBtxKbEpbH8GnMU5Ca2SQvH6NwchnwvB6joG0ibB6aPfyQ/Li9RY/XMe 0jLU09LHblCp5bkgjNMV6XHdUv/HIhJDcYLu+YLqqenTZmB6J7+T0q26edOVe9l1000JDZeS Jv8kHxIHnlXq/+kzLBLffR/2kg0Nqi+1jyYKxnNCGMBdwt8CDXIAC1/d0oecDSGecZHSsd74 MaydnP+1yPa4QM9athPPqlMrGsRWuAbvkxFNc1yp5Ljq7t4hTB+o7S5j7xEFyBIVG+oSVQm9 qS+EeLb/3fJo3ZsyqZe4lfuQnhIOHfB1jNv/jmMtXvAt+/WhCTenkctCfDRf0hHQHCQwYxB4 wBrdx2eL0TJhGZLKYyRzIAf2MhK1DLjP/AmOOQdMkQqB7VmSY8802LeeBJomVjAHOewluHhj YFqpe562Rw4bGg6vJpD8VI+LjBzm06HEFk3ZCJ95FhI+B7aAHpSSkUG6F1rOEpbk22RyxBoS c90MmeIcyIqZly3ZlrwMEhLgGfc0316zS/qQIwweEvXcnjrWhxpX0F8cShImCLc94FLpRMNo EjdjY9wXrxyPqhNnEjTnLN07azcOF0EtWp636ZKc3ROVks+hfy68MQ06LO7/HMj1eCGUwM+x +g8PH6qIhzE1thi3u4nfowomQ/t6RsA9uAomlZMS9k66nwfB38f/5nIJDs1GOWEHUYq+0/wm vPcTs4pN7vIAhLOduxNlbpGI4C6zd5NHmt8eLgh67ojt5OzykqnBChGeFrQ2SNe87A632uD2 IueQbXPPEeEQ0sXeIZyz8KTApqPRfD/Uw06S3tPokqYiouc+w2AV6qgHHB0l3gnb2AoHHgje 9jQHMkYfGzc83rs5Aio25Ag3ghFWQlUefDY3UXIaL/0Y+xzjLGTGNiYiqikebioeLpOdLQwi NNkT+xAN8Y3HyToR+ZE5gXdLh4+s7wQdcQpBwKyBvBCiuZ1D2TkI8Tmz3sKpmMDf2UOI8+nD oKYeOe4G2xzvET4Myl6SVvfD4Oa6QdgWmKGkXO1+FWrZYVlmGCaMGd5hsNkr7eH++6iDOgcP e/ayDujeHcxUuxSoZDYftzLbv/vOIqUkSxP+BHuC+9ePitO1bv2ejvO6eoImjwqrb/uNffbc HpYsRxI72daU7oelD/CP7W7Zi5IBYh++y97XNGLBKoZhtSD6AzZywECg2Nwj0XavZCOQJxOw ut6yuXMkG7fYHXwCWNx1f/s5kir9mgUZERw593PhwMn6kn6C+gX9eNnuaxi6BfoQpNmJj+FL FCKHD7KbdvZ4LxZ2Bv5x9OIUUfZtMT5xzyQJ3wzme5nbOSiuABHoMg3UQ6hvOfqNDgSU2Xhj 2n8IPgJ1ycY4zRj7jlR1BSMSzwokiTh9uBbb5jXYd5BhoPgBmKxaWrd6/Nzgnm3qku50RA6+ ewGxfXs/S4z9QwYtcTEZy0Wr1b9fsOd6fYHY5ITk0SIOdbJ1EugZqvbm6LfbLf+O+DIRRmZ/ IfVuOmxbBGkR7q8hZ+I7gAvy3KWfVb5d4uTfylDuwhKP+En7IvWSzV0iXkhWKAA78MG/OiVh 5XfY4Y5GX2IOH/IfDWW+Q1kriMH/qx8ubEIBnSgaJO6Q8LhXLM03iZh/vQDsHWa+Mbp4/jV4 HvWbb/Yac3qHBNqP8b4D7RqnIdUQ146gqVn0ug16BQIy24RLrvyG4KTb9K+aI5cuF0FmCrIa CoJbGYD4zbe3CJ7gBmwDjv+HEeUO8O9L0AIGFBHfEfWmK/bOykYHQ+7ORFXQzHZ2LtpZ8go5 cbDWEOoL5XZsfwlIciEloPxxjP58PgsWsAArCNym2P2aO01Bn2xf5VYBBS3Sw+4pIRGca6ba KYBEh2yFrkwNiLzs2amyg+olKNfa7rfhpj/Qa3Hvgnl7AA4viekj3nGkjkaseUbkWfyrEvAz sLChq0DxyPEleLSEXq9Bkqa+RGgDGvEp5awoQp9i4wu6/v6Y7rR1RQbL3lSdkS2WAWlv8nqk nsQ05DTP/izykvRW3xMNOCen6T6H1lWz6goB7uyGsjdSTbZuH8+6Geq6wqHTcRZprPyueycX wk3lVQdLlWSgRB+haROtRSOEUAInJFpTBToXpXkiN/ZYQLKMPogWD2Xr9O8S1NDseZEG/Sd9 ED1AlktFmeQ2KsgGi16H/+fZt4PdFurkMVosJ1VByP7Wzf1y/ZJp3hEOJmXJObGDFKFb44NJ rqqtNAXPg2y5h5YC8D5sbjzLluncf4SaBoVc8lR4CGYzWoRnnOdoxLM+ymatEnr7dQ5SaVL/ a3cBksxXbkIB+SC24zUHpNhYbbsbR3Xuz45tjPMI8Yj/E0Q8U/oZZLBYC1hnWG6xJAcJGiZb TASNYG5CHyAUHN1sHXcFwf/yGY5dmnrHYEXosM3+DcEhy91udw2fDJLBVRoT9EI2zglD/scu B+swqxXEJDz/PBHZ/////56VlN2O2p+Mn5TajoiD2sDX04fxFPNznTHuXHIfqk9M/////x9W e2aHmbrKF0oxvK+C9MblQN4BVvCgQVrbr7RQ31qG/////5xP3hVFSiO1YsO3W6fX/uRJhS4P JVDErX81Ds1pldNf/w3+/8GlQIPtMyG2+jE1pHsUSkxvicoWyUkflv////8Xf1fPw/LQ0svW 52ef6DyewK9f68SQ6xMhZCruwEMJ9vj//6XmFulU6bn1sumW+OSi9D7x0QsNfVAjNf///6Wc dekuvDl7/HArHyl6Q+mDGCvKkSYaYbxvEv///7+Uw0Ovopq2TuNbdJ5wf1K1QRY5JGRs3fy/ 0d/o6wcq43PJk0NvKy05LnmR//9/oZKckC1Ug1ciOnglrk9z67TDBt697AQ4Gv//Lf6MFmY1 RcGuzyFgXEwD8m5AnsKfxd68o7X/////XLGufG4aa98CIhgepmiy9xsfJ1BLaXZo9M0V4ZEw 0OD/////AyRnZTymlaTUduy8HEPCMsTwbFLOautB8rPoch1VX6C/wf//adQVLqicaDUnTrkd OHBFPnjYDRQo2iDF/////zk9Y6+KcAaC5PNdEwC3rvCULG+GU0moQoFlqj2FdJi0/////+lh 0UZpeux1+LFN4DYJanQ/Otdb4pDWhsWssz2RCTxb/////5cX0eR16uC9WNnOLcUZgdTEd3vg XqY+NJC4f0+Gnb6V//+N/971pynqxlf3i366Qppun/kHDJarx9WlT8M4//8b/TWlAzvsMyzI nFxU84CuKj6Yu2s5qWFkpP/b//+wwAjEfhO9cNX2VjJIQ/JXouyGMIUhOkVJnZ4t/////5rF HmqCQ/39J9YHxcBBRIMrvHwZXDrmYjRkZFH5Mq9o///W/zJP3Wcy+R6bGlZ9aJzu/YOKkbky NU9668zI/5f+/7alrkz3/XP/gT0b6WbX88wf2M3GP2oDGrai/////zsx8kG63Fvg/CE/WR+4 3+Udt8GXM27n75obKhY25gDBwdv//1IfjR0FwHHT7rFRvS5WUapyQ0p5y5P///+/EfEtZy+G KmZOvaKljIa3WGC4d0W1Yw4VRxko0RSv6v///1FVpCQd/Fiy77sG0BX32ZqzqUxltIoGpjkz O///L9CDpStVAi2bF9rNgeA1zD5Rn4k6CVJqByP4cgMv9fl97uAHRW59NqBmzeNmeUcHy3wf 024T2YWu4yUJOAYOpaRd9QMPdqQF/1gAEpAmWJgA02b711wBfCPRDf0XGPK92fn63yMiEAYR Knf9S2wKd/J6xLmP4HqEou6ceRrBFoCEfvdFMnvfF4aGyPINnpBTGczepuoF93uToyziCDyS svgCmeI34oMV7wIQU+8iXLq6yA9uFJWP7zG/4i3PmoCETSbScTa3DOwTeur7WfaKWeIDhxwj G/HiFqoVR+LY9t0BLd8O+M3db9QyDK+cO7cM8goC+/oCCmaTgvKRLRzAA0WNTeLW/AZvIrAt StQGonEl0SB6y2H/C2bUj/uxc6cKq6g2+wptSMEgo9wfsD+LZhE9o38zj0Iwm+TZBYUU9RT4 HZBCBmQU+3efpZbzjIZDz2l8N6vACZhBR+KL9rC49B36t04gEdmwizNDT0cGjCbtgjc5Vu0b IBaROHuztVNq9nybbhaL7kwXOlsRMYQ+wnw8Tez4aiR+Y3Q8DjKWGnMgrr5gA5bBBlZ5gLFH tHYRlzdAsUG2k3/RnvdWw24bqwvJPewS8BnbCbLNqFOotRAYIgwzKsL8NhRvx8pWUkfm3sVh VqxH0dGG3fkK2qyo7ovcu8WkEdrwH/6WP20L/wvr6vkCoxn5Bgle8VA9UG1DqEulcTyJbNQe Uu8GP+o8kh5rBa/5yg/zlMFDRKItcaIhSYfBCP+wCP2idH6c72cO+Xeg5q084OPsIwUFwnm+ nRfF7xQGszjbZph0qXg2xwbQtPyrL9388gT4Dbz49VKJ9U2kxdOuUJyWAqwLsHq0FXdTClfH a/uW25PDGpWqG9SqV+OcQmGs0VegfyP8gx5/ZLLtEdMQnCf8nKCcwa8IQK6Val8TBRlPPnTX zsiisY9K323ude7iQDoVsvUGX4nS2Sph1vYI+3Kxi9N5x8FIEhySjBUcxp4xiHO+iF+kFqDP DN8HxbK6kzNHIKJIDsiPCeS01iKQ+ejqZLwlrvmILALeIWBUsg+PH7KCCJsb1feIg7QZi3A2 6YeRw0PjeEIXlkrXsAk/z/gRLOAr+fVpd585u3VcCBnvrKLMx8jIQxfehcpQf/gsKns8/PkC 8bExrBK17rj5Es4pXQNhOGYUlPsLUOITdT//QkIGrEoa6e01873ECjWKFXI5yIC900OC2Wj7 dMHzPC8Ez4WMPLnFZh8ldEAMQhzpMsjJCxoLtWjkc49dxhL2kjc4lLEZsgG5wG5RdOclJwcH +roQ+pKTHOTykiQD6BLok2eH5LjGC+ZR+smnOckUB2L6F13oWS/kyBcF6AMKmD82fr4+VcnP zpunvBsvmhU4H0oCmjFrgRiHMEzBjPv2ExwbCphT6IfcETVbhnwnB2fqmqlWqEENKcqGsO6k X3kPLuSd6y8fD7UxWcVxPdipHnOxegJd7bq+nOj3DMTpxuW6kEoGhZSB+/i9uRy/+03nSczW dRikqd7qE1+dHjuWC+rSA+qsH/pLsAHtwCtz4BH9q3HdUvCXYqPyo3PjosSqJSmxQjg2c/nk q5jXKlrw7nW5/oUUWkYAE41rRTvf7bkX7ilZl0pYPf/HBQAJEm53kLtB8ARFvw1Fqm1tulWH BlEgCN4UoNIQP4m0/X8/AzxDEjedsf7xM46bBct1lmXZduyL/gUC9g7ywgzm7oSrEscjLpQT TkTZyRe/m4l/NgxU/AaP+bWFEf/X8E4Y6lvvB2v3B6n4G2wR8UPQFPH1dXQrLIuajP++luyv ZSbMpN/wiPDo9zUbtRv+3xD/5nIRr4ZZ4RpWol+7r+JKCKCogHe5ZoCF1oW/UJzoQyoGGDh5 wQOOrHsG3F1Zuo0j9JD5eQWPFx129TEK+//tv5lxJLS0S/sHwU2IzlbGyoj+xsOM3sa7B2/c aL6gjObGm4CTxtRvxqWOtnAL+PbG147y8vHwTP04Q8BQ/LlwMhE9s4cRyK59TQZMS4nJBKwr zfD8SjJJ4kbxQn7Rv/JbhvMAPTCsoGDyWyQ48lrUV/Ww/+PJmqJzCSyNUf8wEyLyBEv6YYDh QROYc9z8/Hb41goCqQL1eVnnHnuHDurdMyxEHUH0XnsvMXEM3gYGyLqPhKM2BOI/eDg39eqt MtExewPhvfAfT6R5A/+MowkJd0duw97CbWJW7P1QODUtGAgBrfgm3vEojsOoGybbWvfFkV2g rjLcEvOxK32CPK2oaQjZIpD7gzVB8BoFr+qkE64VNKdKWJhE+8mRk4cY9qDc9wF5Tsi4OvbW 6iEez6736GBeOvnclnv8dhVWgi83ipsNPJYDknLpBotKbizHqm4TXP+PCjzArUXGxqqBAhGt WfRT/QaEOJgB1X8lO4FiEaMWjzvhdd8zkBISD/BYqpmrzIBov9hsEw3x6nrCoU/X3e+A+14R CjTaDPAi6JfkWpWueK2SEgff7BM+crYlRTNhptk00AToYOFA9kf7Tdhju3Hx+rUqI+j2uLAF ty3sy0X3LSR7gchvqPbn97GivrrK2a9hGLBKlUAvpZAIx+IyAsT7EDfxpuwC4L4pqFtb12E4 yAZg7NGWAvXK8Yt46TFkxRo8/v3xtZcKvHeo1pxyUZOcewUVf+a7BpioLAkb6A34zAgWyBDc pmerC+4n+fa6kj5iPIj21wiuG+zRbkY2oh5KzPxixDw6v7YFFIDbikeln5koc5+ggxVk8Hx/ kBkPFHVP5nggBAelxH6PkrKH6zXwxmgziiO5o/HdNoHwpIMpHEjwtqBhh9CsNm85247cEQ4S rw+desTe5uuA3AaLzw18/AreyG1ucUYF8lxivBEl0TOq+VKlpAXeBYWx6vINKvTwHhsA1970 yhJnEwrzEh7zFxXmkMu+70wjBvL7Xh2QDHzwwVaqO/+BHxtxCw0iY0PGxwN/KIf4DSsantsg qEH8ZBt18Oodtm38eocbyu88EdFKwdyC3oH6SnirUjNx+Y41c+kKRjO7SsgFmjjpJb1S8M1o SqjDakLwJqE4+v5ccDDi62TaEg3zetbAQQ1ZFuZvjALl+DPo6DXGE+CjQSmsDk0dooVazgEy jXjxUc0fJBzwTqgBrnTeejGxofjZDeIRHxKS2Vi65zS/u2VaYqc5ks4P3VhyOdLsjgRfHxle giVePN2Rp6GSKVo/V6K5z/eMrcIfshJhBZ7n+UoOBEtGPSg4xmPwHoaS2rQ1pfKB53u9mUYN qwp+WXdjQFUjDUI2VkzCjcP40xKPBfCqPjXyormntiouXVKfjDODNbMKZu8MdSeyMwZv/1G1 9nfZ2LNzHf1OkmswhlJY1zKKcwOpmoYgxHpM/QRyaH9rolxUF/IE2o75vREJCLun7XDlPCKo WttIcuWGUIFn0POWEcnDBHqBof0DscdghzockvX1rBOMejEajKc5aQvO3A8YvXr60liUe2eA byN/uuu6a3mq9Uw6SRWgcvjxow2LccPB9fIgHk2MjM27utJLlO93R2OH9s31+PCv625uBMqI w43/0hHcHiaDXha4ZW1mxgXM+w7Np/5j/Lq2ZHYa8Z2RAYTGRIv7hDD1BoEUyhItMyulR2Tk 2qhDWkO6I0uxmLA8De6QZ2SQobTU8As26+bFBU+y5zDhtnoP70+XOE+FfgbY5OHDJhJ+/FwC Oc7SzDACXzyUS+RsVs8qpfyZOLEL2NMhkpUU1x0RuiN4Fhxx7yN5OPyswRE0VKlsqLpsWBcx ARHkFbbZgpspqQ6+XSSQkgH5bZKEYDb/hHY2GFIrgltuo5ENG08HbDnJw14g6+plif/YAjvs 0vn/6xOys5ktRZ4FmhhikP3FzJKWWhOYoX7RmgzPimMGPC85LIxWHP7mRoaSgyj+pqKZ5GFJ Ub1abhZCBhn2eh7szFDPvj8mKUAKYJ6RZ7pVxl7lRplaXRbLJlwwyn1R8PkWz0G8BRkTJFdd unUg3JCdT4Tez2Xme1oHZCP4aws7yCFugP5iu0tnrVECYyLskluJkun5OrZwBO0+NiIOQ6N8 nuf0T4YFOY9ykaVcD1eOaxvZXisaEBZb3giWkWVkX+FT6FerxFlG80slGOJSOKg5LphiOPB+ bfaDDEk6Et9VmES0U38SDO4BvtaWGzugCtINa3Bme1LzDgjL72zA+QuFuQ53hxJD8j4cgLNM Hp4fGqp7kHuC6upTEq+Ri7HeiJ+Krp5qikwTVZgrhlEd9fkEIdIk0og2cC33o/tR2k+hDiOw 2W3jCwSpIPInrf/g2cEWey3NijYZn+2WpdBwAAANCgFJbiB/sP//YSBkaWZmaWN1bHQgd29y bGQVbmFtZWxlv91c+3NzIHRpCBMcYW4hdG8gc3X+b3/3cnZpdhJTbywgeW91GGlsbCBiZSBt aW639tvvFS0tIEJhZzkgQXV0aE8iMjlht2/uLjA0AglHZXJtRHkufW//t+9qAAHojkCQo2yZ QABoDzgE/zUE3+0a33BAFCGKBTZsBBaxkGpk2v7/dwdBbuvxycNVi+xX/3UIX+sIR/YIgO1u /5ezBTt9DHXzX8nCCEJrT0cAEPsg349BQChok6gOcIEFcVAebu3/ZQAA6ZX+7//M/yXsYA8F KGEZGRl5JCAcGBkZGRkUEAwI8hwZGQQA/GD4MjIyMvTw6OQyMjIy4JxUWDIyMjJcYGRoMjIy MmxwdHg5NjIyfICEv4hgns/n84xgkGCUYJhgLPl8PkegYKRgqGCsYMjIyPOwYLS4vMjIyMjA xMjMycjIyNDU2Nx8Pp/fYYlwYWxhaGFkYcjY5PmoYaQFnMjIyMi0lJCMyMjIyJiwuKzIyMjI vDg0QOHIyMhEUEhMYdlkZGTkeIR8gDIyMsKXFBAI5DthMgzZYAUgZGRkZCQoLDBkZGRkNDg8 QGFmZGRESEwAAiRUQSKaqaL6HcP+9t8+EASMT8vDz9QBy8/M1Mj6AG3///+ptbyurbuov6au k5ef+p6IjJ6elpbUn4ILptn//4EMta+uqrWprtS/or/6tLe7s7QJ/v/f/rWorrW0pQ2uv6i0 v66lqb+5r6XJ1MqlzsrN375tzyCqvAqlYKXDwqUkpbe/pWu3bdjIsRgMqS+0vTkQ+c9uB6i1 RbmuDKm5sr++ych2a2c/rqy+twmsqBjLzAy19v82sTiztdetqKrXzsjL10gKvbnug5Sxs7a2 TLleX66vqreZO7Yvyxe2vhUJHLu2J+QPc68Msb61rbTIyn0sNmsAEEIKuba/uyP8P7aluQu7 rIqIlY6fmY7Dgh652MJZ+7e9qL6zHii3E8ql5GTtNrnnw6JNDLSuD/s2m6wGbLjLwssLrr7P bu3Zrbeks7m+eaq0pb6/C4O1hbylrvwMqo6jLxvWZgpSB6m+qEJhVnAr2I0ZU585tnK/n7IB v6KrrxxYwApMGCWsv53dkmeqvheiFq6zrLOoLdiH8K+p17k6vLupCBewMCu0v3J2DEStOJw1 gsweEaqcWQu20AawuyKgB5KwzdqpYmnPtYTkwN7+Fc/Jylu4o7gQrWDbgyWjvbi34a8KZd1g jaKDvdy+CdbKEbZavd6yu4UEhn0JjTossq62HSs0Tti2v3q74XkKdnhbADWor5w0w+Rk77u+ ggy0rv1CskOwCb8jzHYyCgOzy2Czqp+MLUy2MaggqWqwMxRmrdUTyIIEYcZsWA0M5wPDTKV2 trMLX0QQG5OWuarZECIZ1y5pSUsgySE6tu3Z7Ui4iL3ICanLotsOxhmUvv68vSagCgtWKgQL kjMMW5aE9q++iMeiG2mhHcYrtJxIrdLbDlsOu6IJqeG4Cy0Jkw0guSAKi5Bsa0Mizl6/GUbD yTq+Ir+1dbNvm1uCG3NUDEC8HsPcsLULJwrq6evfsBIOqqOyr8nXjUKwlmzIFEm/mq9sl4T9 C6+3/Lavmw7htbmGJKy9e6msrN2eZgw+17u1sAgP2LBIKV4NCFrhLTuqs9kO8rUNYcnN9QzF vrruMoZ1HLUJ/bth2ZI17M/PvxhCLqzYN9iWIrYMvbbDDAPPcD2po7TOBr6lStdBak28sy68 uLOMrW7ZMAnuDargLYHCZQm/7zyWNQ3WEqkItoO+CuGDwdjOv3q1h7TzQCsvOa20rafDaA6C ToKOUmzWCwaTKnsSyzgwl7MVqq3AbpBvCrSzorGsJ6Kj0Wa1hzK/uKuWvfufrP1+yKnDAw+x pc3MpcvOycwRZYM9DrNyDL7oYIcHtgy8CbOND9k3WFgcyx3LzaXKD6zWNLA7l6kohZoN9hTL vJC8iGVukmjxrnyqWNdbmD22B73PDFiuFyxzyw614wsiNQ4UTLnGo3UxweSCbkK6Wgu4Bzf6 iYOJ2hd2uUSwpmAhq7Wqtiy19mCiaEYvrMoUSW/YG1cLXeXQOBi0d6atvUsuRuEgEa2yqI+5 huRMs7eC/4HTjLCt0QqE4L8smRhCcyJ7VTirtSWcB6gSC37ijof1WQqpuL2TraOwTBjcGlSn sam2ormDVDBk7yqgu7+FBhGGCaB+tMs6tWAQDY7fadksZrAfCRUiZXHZC8lCJBIYyDK+cCsI BUqTpLIwNmkQWr9Oq88Yw4WAdKuWEazCK21tGDSkFfM+vgSG9Ya0DL+4NrAuBqgHrwouQo1l HahbnaPYthCEO/OsJLSJVoFGK8N+R2dmKpQIqPBZCxFms3e4lgpCWTaBCYulMKUBGmevQmtC 7EcRvIOZGrO5B+gXkKmSDLxgZorA9a0gZ98TtDe3x3C4GbOzCIwHThIO1s2gOqIJqckQZmzB WktkibxKe7RkB+RfFe3SFYj0ZM+jt2rwdUvWgm4JSJOpsSQF7JstC68KkDLYYI3bBrsHty8r dWseyNc8C7SuttDsIdfJCYWxgZstUGD3RLgJdyYdWFfntAuit1vy7Cz9rn6osAt1M0iWh5Yq qh0oVJhizUCf3BJqjQysDQcMGNaCOXYKzCGrLWvkb/ULSsbIlqwwGWMLvA9ePwj3t77wZWZq T0iWrLS2inwMaMGcaTwLDAsaOYK1vgkPL3LMcsELt++TrFUqORpU1VMyGqyJFnOiqAuyMGCD RRYMs46pFsO6JGMKtQkKxLKRb9+pvwzH7AXMrQ3HDqUrCLNbvkHCwwwSxw+mYRSRG4OiRrNW Fk1bSbAmNVbNp4De2RojsEezOhxdWSySRreQgFx4s/kKNL3JKTdrradBCEgrGAYmDreTORyN WVtQvGTBGQ/NDg3WkyOpeJziw1rBDAhzDK/KycJDqFUC0vbCyrQ46YLAo12uqaAzMQT+DLfI zHj4D9v/yFZ9t/qSjo6KwNXVjQDUA3vh/4mKk5+dn5bUnp/VI4qSihsT2L/9lp+TioCTHYjX l5+JiZ8jl2D/BfaVmJOWGpSfnJWIl5tbyE9gX5uMkk+dlZ+OkoG13xYTnYiPg46OrPuHsDKS opuPjpWJmZUFrbUEdsjOH1TcOxPY3beZQNeYlY4Hm5yOJ5iEbwvsl5icGJKWk5SbBitcaCFP A5SUQlsra4VCDW0DXGsnsP+pipuZn5mWj5g/nIgdDrb2IWzXvJaVjJ8+Ip5Fu4UQM5WUldb2 DSG8j5KTkVSP85ai8O4Fwp48mdcelJOOgLbRPoB3m5ibkThDjn+wwgnklJufl1l3ob3ALo1v k5wVjW07hHCdlGiZkYaJkf4LrG3PjllYioiT142V1/JTwht1mI+InRSMk4iOj9othPGAlZTP 6YmPBIwJLxCJj9fq7i2BtQubcBiq0naBbbSWUY0Yjga7bY0QKhvXU46Tqe1tCGmJXoAekZWX BtRwDGF1mcp4pcIuhNsO14hpFUZbYI2IeprmPIEVFtiZnKByNmULbUztlxqQpYE13MaT/YzT rMo2YTtheIjM1+EqLawE95eCktm90ILCEIIrRtQ01/VSO2WmbBzJjuolVtYW2pXRbJlWOLAt lBoIjkMxnj+WhQMIralAEsiPDQuEbWuXHJ3MjP8AmJ4KsKjXJwKjUGqabbn3N8cE8pydkVY0 n5QyNEYIi3tdCOuRwmDq+wghjEIPHtxWKrRCD3cCvcoK7hGVmR5GUy5LpduEiJ5buZWIj9OH FkAU2deVuFwgtTarlbF8kVzHBgkmR4+UH1fWChcInZNmCvOegLW1jpP31KPGiVsaOFMpSVOJ 0gghlQWPkhqnVitQvohbRT0LIQwatm7pjyhcYBsKk6OWdWOEtJkzY517aynZDK6UIdXnlw3X SuCXkozsuJqVYOhMSP6IBB202rbFiRXC9Yyz2oEB1gofI7fjYaKJkogmidhsw8SVaI7JLIM3 KFFqARWaI0YIy1By+WzvCOnC9oDXkSWWmY+Sm2ZaIHGemfCUcrDAlrZhjvKYINX00Y6o14p7 XNdln5bbGoUXdo03X6YFEo0b//eMbYG1nmTYm5QLQggLxzM9TVyDJNqO+1xVsFm3DbOcZpee I6XSVuAtZiEZlMwTBtoEnKA8ijU1HIW7AmRviYVSaZB0AEu0bBvCTM0k12adh6PQSimlQ5Gm QiOEhNTiEVtgJr6Hlg9F60JioWmAy4kYj2a25KKxb5YnjMcFToUF7qeNXyDgCj0ot5mTmcQE kqGMH2GVaLYwhMSQXZvjpba8QG6fgo5yKf5LtlrqpoP634nFisffaLy1haXc9waJ+rtOttFm Wtb6MaTVGYoJbgdbCiScCZCKvvqdnG1d20aKMd+WKr0LqcZWsh9pj4oOR4582m9j7I2UD71J szy/lHsJbKkZ5BxWnxjdWKFjFLaV9RW87Kn5WAMH4gcXqZuMnwaetR6ulbw0QL6TU7kCbrOJ Fsq3oJwFJgqzA/hgwv6yCIcHTrY32/oA2NvlFyOqv7b7PRc7ajL3m/1/+hr69Nvx+//2+vxY AOrrBLPvzboD2g4LG/4ebrbsZAf6yjMGKBlLNrDqBwYM7ux8I6zGoALaAIlF9iqK6jc1fcG+ lmbr/5Cs+LYt15R6GlJzmRDSOyWcTSP+R7j6AJoahyimmXrimNlg4CuklVoLqurukicvJuqS 6gAPZjllk3IDaupkQJ5tmlY+KuofEOrDQccv4/q5lp2yoK9/FBytyA3Lary7+p7GkoOO+/yt 9ySJxdK3LrYYmR+DFvpD+K2BtUbusyT6KfjOyDMqQQPQF7FOtixt21J7c/rZYJ8Iv+eZNnuE K2dN7By+wP8KWJqH9vuPvGrpeONTZJIat+oSYbOSAc/e2Q5ixwrf+t8koE/y4mrlFJJhUb25 9ykLEo36X4KepKpRySFquVEQkk28zvqINkQ92kTgV2hmE9ExVKis2tn69wPE8wYS8/qkUAXf imVGRkY2BY6ChnocgGFGcuf6////g9rL0MvVy8DLtcuuy0DLOss8yzbLKMsiy/o7ChVlAAba nHlsCUw4R9YIjoKOpW2DbZ0GlEKfCIpI2Nt7tZIF6xsJk/fwDO3rJX7ax9rYr4mlyDrYF5/k hrWpM0kat7WYkFVq6U2l0tipmaCKTGcneDKlpKmzG9gN5tyy0zl6OUPU6rLPnUGubTPSg64K WDBntjWjMZ973ecdKrQV0rgk3pvAEiVuBpvHo+uDbDdTroQSaMbHytSVNNaZa/cNd9RB0stc 9y8riNKb0pPT0yeUcB9dsLNYlU+ABge527atBJGzvFGoq57e5Oy9nYzL1g9OD8jZBjNwu4pa Ick3mYKrqxY04p+QSrScK0eJXhXnyAgtIjjdTZXv8DosFYnPQCresjtqL3+U2tJIGYsW7sMq i4+TzLhitb9sb9YEA5bGsq63tsQVgTfovAe/u77jtr/EYH+z3Qfar4qec8bVFSauu8C/VQ/A u6o6rsfas77H2FiLBuyr2NoStGgTbAWWgAG+fAqUXvuwQlsNqa6jRxLe25orCBQxqjIQBtC9 1gw/CRS1Of1nLuCirosYt7uis7ezoAw07FZUrq4sQBq0wMgTzLUyRr23iyC4u3cS5Gj2F7Vw yrS5vxMVc5e1TVusk4EVAtdKeA0+OlsJOgedK5eBA4Al2v5tu9X4qbmos6zaQTtjt1C2vR6s uNDYHZD+Qbq3g7wMi5yW1IyYiQr3Bkh6vKm1Bq41O8mYjYz+ZvwKqT12J9SNsnbBwm7tNurc 2qaJlpxGxtYGUtbKFJFCg6QQNtgt7EJZG2Tm51AKYYOwA0qsEbbKGDkt2LJCWBtCIBE2sEJX IgphIaxsLlmsUPaBSZbNCBtkA4AbHCFsQdbVTKwyAljqXoQEQgkAAZYQSGFUF3WBQApbLy1t lzSwIpm0xZIaLuTM7xK8vlOths1i1JFlIA1OoJWSImfBqVnuYUMp1KirSaCAaSFkytIte80q 8HmIhpCmH4UIPMSNqRsD0iHwgrXTIBYr0r4QiMDV4/f6+7nWaKelXd1uPu7kbdWg/ZOfjZ+I CDank7VGa82jE1fRxo4RC40jP/q/9unbg2/tZOG3k2ZwlZyOpinaVrQHprmPIgmsRWpWriGX psJJbSboxlPUlfqzBIBambe3nfrXE5KOm3mY5CmMXMBjurPWGoaOFpROPjGK/0YFuqvPsJj4 +f7//P3y0oKpUmDHh9/lMJesuSLxDXENOQdhHpWIna8Gt/3CVpe2vKi1t8DGGsQXGtbAwLne Sw7DPril0LsGK7qX7a7eHqX6/PuWnNeJQRi5RGvTbiT6j/oWojlYT4PpG0iJKxTK0QXyBucr 9Aa5ln4d7Z7XmYrW4BoMG+SKBextqGbuBY6egwc8B6VCYZGCH3B7ZqA2Wfp0iWAAItsWLLR7 p/qrgmOJiuZu0J76IY+CBV3QxqBm33BomS4b5Fq7d5KVtFwEvJtU26VogCLXmyG6B8eXwLbw lpuY+jaJa80ZbpWVnd4Nq80c3VozcJeKLH/CUvqKa61trTvXVpu/C5QamrttWxCdMLpHitSs UtaCRtspg3wt9KYY2tbcleaiiJe9plzdwje1pvrQ1NDdjWnUopt1nBfxl4mdAIkFBM2YefuC l5YenpiCBJ6fXN42fxOUmZKXnDyVnomZnFw7xMEYeQQhsV/BFXYhJ16YmFS79sF1TpYrMNSP zzWdk21u7HNEGJ5ykEDIkhqGJ8Pnvdq1nDHjtGDaCqLJna6RLEbDtmqt25Hj27gptfchtBGi qtYLBrniJ4cvjdqxn4MTNsyl7DVfLSY1rdAObC2qGU8RFMqttYkLBAqblnhopVcuVdqZCpZI FV2XXbfb2yraN59onQy0/pvTWGWLeIeOe4loJbxtMrSTHQcyjpGDrFUxCp462Be20NpZRYqY DgySGMNirYlKggA65Rkd8aipCFza3Tk4ZqLqIbuSDytgW2vvV0HNMrBLhdx2tpXdklnpgptc rGJrDSWR7YKi7azbDsIxjcOiANrsKcrmHVyIG4lHwZbdOLt+2swpEdGECe7P2qpsMD7ots2C lo98mEeqkqCtrRkPBC3DsI8aLLQTaLcjGIKUZaqFDniMS4862G5NrT6kMZLgj5gPjgoNYubs RHZSqH071jsM+p4A3dbd2gXGrebWZQDag9pDssCP2Da20sA+Cd8qkwPIDlzd1lsKvoTAWT/M atC2lQfYCC89AZcwU4EQbvQtddLZLLeG1zvA2KhR7B4gy5PXVo5aEDwVjFfWum8tXgLXroOK ZZfVsO3W6qIp1RuknsEfVqhWsNoAPwQYmgu20YOS1wB3Hkb2hrm8DxFPhsamh0bVF5bBaY7R ajQTbD8fJgABa7RQkx0seMUGLcqJ9ddqUlnh5sA5zZg4XgbaodYRV4BUeOztIHuPUZh1n8zO IiK0WLGdZQt0VGsUY06hZcEmLLAYi1VLUWAq+xTEm5tO1hpfqwO4XtXVGBeELTvQiS2xsGBv EBKV+gSe4M99bQMR1BkDxpiI78GH934JncTGHhHZa7ESxgkGFuRopa3Sxj5QiahdxGAnXLSe wBLEQKrs2KHLy3Oeigza1wkNY7M3Fg0AqBK3Lr4JtIlI0g2yhGrs0rGVCaObU5XbCq4Bayw1 /3mDbA5Bh9luVMDTDb9N2jGrxoJeHr4ZA3uZMLiE+B1bcshkFLe/jINDw94QHFzY7iDEWpkG t/q5fj1cDV45iy7BVqhC6Q2lBjBqarVkT7ybgkR2zy0WVOjqngFtCaOVuWWRaxXaHp01msER e6kaHKUIw2Ui/w6MDfuWdIoynuwA2nN1NjubBRDUfgTuZwNXseKTjIKeBEMbVpiTdiq2tFos unLaV21y4IJsdJGJToll2CFsD5iTEIrCirOGW9Zw1I2fFyMZ1AawQWuKBguwQ10OifBwIQB2 GUfXbLoFtmyDM6+JpDQ6eGSANzWXmSmbsA+Y1EW7mJMto2GPrV+chPACCEu2I/dKrh2ziCv5 lkIcnAJCnh4IxuSeodeiGy0acwA77NE3jcKGwGUhETYbu+szfiILhC0sWNIDmNRmgmIPDDVx vseTUimKHJCMpeIOqeuW1N3fMfr8pTcxE4cNNrffHKGwcEjjozGlHCFcWWhgpU6NVKUzlNxb lLK5nKW2/9IFGHAdx44XjFNta7H5+k8TiSEVmupOWINfu5YspV6eXCXcrk6wlSl8HINobqYC X4mllJw1TN2cf2aPnIABbQStnXqbB8WPk2uO3NcdnhGIRO+sxWzfs5gOa6mXU7OGn0wwNHyE pQ+l6x7WMtVaJN3eLII2WHCOgowLjE2Tu20xi0CKkIGOrj5zYJislCGJIBfkcnNvREi7mZbV Ho+K3KG2TawYjxckMoxdzBVSuT5ojqm8X7WKEEMX/ZanWsBgaKjvaETBHLmp9F45tdoihaQ3 knCobbHKp3datAIfbIP4jqonlza3j6KCrQPxbwGuv7Sjsam+cVYbtRjNu4m802jJqf8dtEZI FOv63b7diN2V3Yrv/oV2AZ/dKqndkd2D3bQLjt36pU2z/fbXlbWbSYbX0anRA5GDtP3b0jSf joZlsbWV16X6oTHiUs5PiKaApx0/a3C0iYNqRZdpsJGWqc3SNVOXUgDXxK8/Y6+ZxgoRaaep 15Hc+Rb614PXtNdQjl2h0KqR4Y71rPqg0ouAo7DUhe25ga5Sg8BvPvrDorKO7voYakNbSHGK D6bavNWE1jZTjQcIXD3WGMz6B64nUrO5q2CjW9a2+kMNvjawh21srWopyJX6QaklF6GrjGmJ vuAO3VIDVzMzioNDqjVHzQBaB4xUZI4KsFm03JqLYSxJvWW7JfoRzxE4OonIRoMKMAq+2oT6 cwFZjIpcIgAJRQILJYkD/5fLqTQBVFABR2V0TW9kdWxl2BYAy0ZpToNBE1gLgP9Qcm9jQWRk cpAP/+y3/1N5c3RlbURpEGN0b3J5JFRpY2tDb+zbFux1bnQNPEYbbWF0QQ9jbeyfWm9uZUlu ZhVpCxdXbf+E/WluZG93c0tsb2JhbEFsBmP3v22HDEYdZQtMb2FkTGlicmEmz2LJug1jJQsk TWG7Nff+cFZpZXdPZsIOzGtCea7vW/t2VG9qZGVDaDwUT3BlbtNr28FizwgzMjBy1g/N2u4B TmV4DlJldEohgN3NrWdnaWlEcoJrW/d2U3QFbmdziVMYRcVxtd3PDQ0IQXQfYnV4da39giET UG8xEIBT2iGCuwtlcAZHGp1t27b3HwkVVCFtJ2EZ4Rf2ZKJVbm3VV2FpdF3mDG+uU4AOT2Jq OxTf7S9ZC0v0FG5FeB7hdrZ0MnJlPWx1cmOYyx722QltcGkKcHkJLvZasG4KMQn8+jDbZmei R89/egzhCx+PEFR5cC9DkXNlSGEQDwz3XmobyQlDddjBCoVyqAbcSWQU17rPAhJvbW1FTMBV BHsHx0YnkHYOm3sDO68PeHLuafgP22VHQ1Vh+29saGVscG6yX1jTU1dwc2hvdBloBhu24bBk DU2ueEENWpcwQ8dNcGQTDNpCssJvHwo/YRuabO0SvlJoS3PmbqdZWkEIFmdEGRTM4d7CVkR1 OBAWDWz2ZG9FdCBLZXkOcmZzb9kO3w1UTpijnZ0gIULwHw3Jbk1vkF9iSkRDttmbHUptfV8W CeFjO4w5Rllv5GywjW2CO0lQgyZ27xizWWtRXA4vz7h2w9xsCD7GQms329YMZ/xUpYNRcqdY 30xJNjRRMQZtT25I21qHSdQ7DmppCuFpNkdH1WIAU6s0W8OjbLVCQUVuQPbYG+4/33JJQQlE dXAI2cZgbgISVIVtCfWn6dxSJzl6WFVSTESmm+S6ZW5sQGkchWg2bZ1gfXDJdGZNHTss7DRh Z1BvkP9za20ZZm2VcKQ1eneVGk/u3hxoVRuqHE9P00mQeEndbrrsa9mSAhR0QQ6MgJUuVVwR 8zZD23BublJlZMMvWZy5tu5pjGkfX7xkO0FAo7GedMD4VZidzCEMYnkOSHnpa8BQWGOAcwNr ZXS/yltuYr1yYWNjJVNBgdccd1xydHUwIxl5NvtmrnYyehRsBz75L8dgzVBFTAEEAMwPkECe NP8P4AAPAQsBBQwARFZIUPsMBwLfWA1AC24WbDkCBDMHDMDO3JLQHjQQB7O8JN4GT9Bh3F0g kMvAoAOnxPuarrABHi7DdOtCkHcX9gXrBCMgHi5yZHSD7Qqvo0YL+wwnSNli3YVAAi4mR3Vt SprucCc6VMBPBhtsgXOCAOvAc47Av9/KJxtwZA0hxgAAAAAAAAAAIAH/AABgviWgQACNvttv //9Xg83/6xCQkJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz 73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78 EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2 D4oCQogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5BwAAAIoHRyzoPAF3 94A/AHXyiweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4AwAAAiwcJwHQ8i18EjYQw pOMAAAHzUIPHCP+WgOQAAJWKB0cIwHTciflXSPKuVf+WhOQAAAnAdAeJA4PDBOvh/5aI5AAA YekEbP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAGAAAIAAAAAA AAAAAAAAAAAAAAEAAQAAADgAAIAAAAAAAAAAAAAAAAAAAAEAAAAAAFAAAACk8AAA6AIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAEAAAB4AACAAAAAAAAAAAAAAAAAAAABAAAAAACQAAAA kPMAABQAAAAAAAAAAAAAAKDAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A /wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3 d3d3AAAAAAAAAAAAB4iIiIiIhwAAAAAAAAAAAAc4iDM4iDcAAAAAAAAAAAAHs4MAA4OHAAAA AAAAAAAAB/8w/7A4hwAAAAAAAAAAAAe4D7//A4cAAAAAAAAAAAAHgL//v/A3AAAAAAAAAAAA Bw//v/+/AwAAAAAAAAAAAAf/v/+//7AAAAAAAAAAAAAHd3d3d3d3AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////// //////////////////////////////////////////////////////////////////////// ////////gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//////// //////////+IwwAAAAABAAEAICAQAAEABADoAgAAAQAAAAAAAAAAAAAAAADY9AAAgPQAAAAA AAAAAAAAAAAAAOX0AACQ9AAAAAAAAAAAAAAAAAAA8vQAAJj0AAAAAAAAAAAAAAAAAAD89AAA oPQAAAAAAAAAAAAAAAAAAAb1AACo9AAAAAAAAAAAAAAAAAAAEvUAALD0AAAAAAAAAAAAAAAA AAAe9QAAuPQAAAAAAAAAAAAAAAAAACn1AADA9AAAAAAAAAAAAAAAAAAANPUAAMj0AAAAAAAA AAAAAAAAAABA9QAA0PQAAAAAAAAAAAAAAAAAAAAAAAAAAAAATPUAAFr1AABq9QAAAAAAAHj1 AAAAAAAAhvUAAAAAAACQ9QAAAAAAAJ71AAAAAAAArvUAAAAAAAC49QAAAAAAAMz1AAAAAAAA 2PUAAAAAAADo9QAAAAAAAEtFUk5FTDMyLkRMTABhZHZhcGkzMi5kbGwAZ2RpMzIuZGxsAG9s ZTMyLmRsbABTSEVMTDMyLmRsbABzaGx3YXBpLmRsbAB1cmxtb24uZGxsAHVzZXIzMi5kbGwA d2luaW5ldC5kbGwAd3NvY2szMi5kbGwAAABMb2FkTGlicmFyeUEAAEdldFByb2NBZGRyZXNz AABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAARGVsZXRlREMAAENvSW5pdGlhbGl6ZQAA U2hlbGxFeGVjdXRlQQAAAFN0ckR1cEEAAABVUkxEb3dubG9hZFRvRmlsZUEAAHdzcHJpbnRm QQAAAEludGVybmV0T3BlbkEAAABiaW5kAAAAAAAAAAAAAAAAAAAAAAAAwwS8kil1VROPQr5o K46bcS+enmKoLQV9lHFGeg0iQXoHp4FVPDmqTEAomVSdUHolUp+gupKtSakHPiC4s6RuSqkz VAhrlELCccUiI3ZzH1uoHJwSrZObxRc9mqASjwS2NJ4cjbYUIIWeRXJIMgmstzhJipBFXEh1 nDojrYQcnMKUczN3DIvAnmICYwqfAmwSNxeYarYouwvEDMCOWQKHACvCnm+fWaicrg6upXN9 Wj6MGw92dR7CYDQgvBiLlwQ3uoOctWGCDT1egCwZAzMbC8ULr225CkuXIhCcbTE5I7tknQGJ H3OfTT+UAUBXloxlUSSloIcIimSAX8Avq30AIcQiKbvDhLHCZx8EF5lsc2WjBkpvgbhQDHkH v1QmvsdYOQa5wyFIEiJdxVGPCXYIZ7uiFzABtMAjpReKXKvCwhCFjV+gf7ObB39rYmGprp2o vJBpGbkrorwwOiNgXBxKFkFMpsCcV7A5jjBfxyCfG2cSJDYRHW/BpANRIDK8JFp+l0yHWkaN Xg8Mp51lRH5BFhcxc1FzCrMGqZ4JDTW/XmynhwxjkQhyb4Qsq5dDIhBOdgG3woEiZlo8TkEa kQilvqeYOq85Jq4ys0+vEQCEwsGMRTAFMl1uHzCJC5tcwh1rMms1w0BHOYu3J6gmoAyPulah PwuxVIhsP1+WBZYrw2hIm3ZnM6fEALo5NzBchneKsBFah2Y5uqwHbQOQS1CBFxmHQ267th2/ KlarUWVgWJVqmBIegkVWHwgvnUE8SBCVObogiMZ4gWlYTFKwhq4EolknBrt5tGKwUYsqkVh7 IpVpC1wEcAIRioOOhCwAd5ZKCpa/wpaDXHPHjqeHKGybuaa5DHgFqGfHGIaYBC3AUEevE4mR UHhFUDZlhjCVWYOFczcXUqNGwYEMkWyJlVCWQxuYAFYqboCjqBqbsi0XwsImClsvciSOlg0X sSuwk6YzpbFjNFhKvqepwAUyjy2tIopAD6WlJj9vQR5MnIcVXEMKeZBBwmGCnaCrCz0/SYt9 NGc6iFZ2HgqUwTt9GCl8F0A9EEMjBCN3FyxdfBZQHlQVrDZQZUQvThRmuaEBQwySR5WygcOZ HwefilCfvhxNU33HeyQOxFCPV0UFvyI2lzBWQKkFImjGvG9zVMB+mGh4KlKjBiUmdWhBXzII SlE+f3xUQzArmUJ/PSyiSryZlhs5Ib0pt6KDoouxal89wFMLbSm2SC+Oipw3IJ5grSF7Kmsf EY9ASlxWB6IbbrNwakeadGMFYU1CgABEnodGklCqTII/lEZ5oxueZQGsTayAlcevol67vQtd faHHNLKoAhVCjkIuoViOesNxYhuKkX2ALpuxsAsPITF/eoK+BZFQKGAVlY63ErGTZJC3hH9t vHS1QxV4e1cLYVaWfoGMXQJzbY0/r0AgmqkMMJYTRS1HJZu8OgYhbyMIaTGxFblWM5BZB1dF bSQLn4JpLbxgkRxgj5UOn5degIKkZzeDa0h9bYMvecI4Ex/BHkOxbAhAkEo1ia+bNW1aUKKE soBauZdMNr08tkcuc6F6MLJjFGQyhYaSccRIwIBvDoMYn6lmZBZ6pK1UIyoHRUcVprMJkSm6 tbmWazMMimcexJIpCBEXWAcbKQYsnUKbPMetvnkhibY4VFoqJEGtQhaTIwGyI7dcfau9Cbd1 XCYaJGWPn6IQS70UP3NPxECwLVO5ER42wZsik4BfFZusBRmYNUlFA6x3V5o+rMIEiIEdKwsI gWwgszVisEelXVZ+LYKYriQ/Pn2nGjcnhiAfsU52l2MZtII2JYU4b4C3pXhZjSw4syVxiRDE o0OprksqKG8CLaDCUGBofsdGxGcqdFIIHrmbRlUvQgC+lVOSk4mmnE6xrRxjk3Yeqll0mKuv fmZuq0ocCHiSTYUaSaQKoyFAuQBmYcSYLCctZ2J2TMWVK7ekh0NZcVOyiI9wZ0Y7N2AukyM/ BygzHbxQAqVfx74MvkO9o6erYEapWIMKTDRxsg== ----------suvwnbmmuzujkjlrxlxy-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MNJWMV027353; Thu, 22 Apr 2004 16:19:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3MNJWBw027352; Thu, 22 Apr 2004 16:19:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MNJSU2027346 for ; Thu, 22 Apr 2004 16:19:29 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BGnTi-0000V3-00 for ; Fri, 23 Apr 2004 01:19:34 +0200 Received: from h43n3c1o273.bredband.skanova.com ([217.208.170.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 23 Apr 2004 01:19:34 +0200 Received: from jas by h43n3c1o273.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 23 Apr 2004 01:19:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Use of NFKC in SASLprep Date: Fri, 23 Apr 2004 01:19:30 +0200 Lines: 9 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h43n3c1o273.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:WqFBhDWsQoYNh0oxSqciVX3n+zw= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: FYI, as SASLprep is using NFKC per Unicode 3.2, you might be interested in the NFKC stability problem discussed on . The page mention a strategy to maintain stability across NFKC revisions, which might be relevant for SASLPrep. I'd be interested to hear people's opinions on the problem. Thanks, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MBV9aj062302; Thu, 22 Apr 2004 04:31:09 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3MBV96Y062301; Thu, 22 Apr 2004 04:31:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MBV3S4062293 for ; Thu, 22 Apr 2004 04:31:06 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BGcQ4-00062g-00 for ; Thu, 22 Apr 2004 13:31:04 +0200 Received: from h43n3c1o273.bredband.skanova.com ([217.208.170.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Apr 2004 13:31:03 +0200 Received: from jas by h43n3c1o273.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Apr 2004 13:31:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: SASLprep examples Date: Thu, 22 Apr 2004 13:30:58 +0200 Lines: 9 Message-ID: References: <6.0.1.1.0.20040421215045.02c94fb0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h43n3c1o273.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:KGOMnWAEPx5S2QuPpi/HYH1Gb6M= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > 2 user user no transformation > 3 USER USER case preserved, will not match #3 Additionally, perhaps "#3" should have been "#2". Thanks, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3M660q9078246; Wed, 21 Apr 2004 23:06:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3M660fr078245; Wed, 21 Apr 2004 23:06:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3M65uVR078190 for ; Wed, 21 Apr 2004 23:05:57 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BGXLT-0000W4-00 for ; Thu, 22 Apr 2004 08:05:59 +0200 Received: from h43n3c1o273.bredband.skanova.com ([217.208.170.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Apr 2004 08:05:59 +0200 Received: from jas by h43n3c1o273.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Apr 2004 08:05:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: SASLprep examples Date: Thu, 22 Apr 2004 08:05:56 +0200 Lines: 36 Message-ID: References: <6.0.1.1.0.20040421215045.02c94fb0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h43n3c1o273.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:UDlkqFH6HI3/m7JsMlIjXYgS5VA= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Kurt D. Zeilenga" writes: > In response to IESG comments, I have prepared the following > examples to be added to the I-D. Please verify correctness. > Also, if you have suggestions for additional (or replacement) > examples, please provide offer specifics. -- Kurt > > > 3. Examples > > The following table provides examples of how various > character data is transformed by SASLprep string > preparation algorithm. > > # Input Output Comments > - ----- ------ -------- > 1 xy xy SOFT HYPHEN mapped to nothing > 2 user user no transformation > 3 USER USER case preserved, will not match #3 > 4 xIV output is NFKC Shouldn't that be 'IV'? > 5 Error - prohibited character > 6 Error - bidirectional check I think it would be useful to add a Unicode code point for a ISO-8859-1 character that is translated into ASCII as well: 8 a output is NFKC, input exists in ISO-8859-1 This was one of the problematic code points for backwards compatibility in DIGEST-MD5. Thanks, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3M51x09050560; Wed, 21 Apr 2004 22:01:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3M51xbT050559; Wed, 21 Apr 2004 22:01:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3M51xsL050540 for ; Wed, 21 Apr 2004 22:01:59 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3M524Ms003216 for ; Thu, 22 Apr 2004 05:02:04 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040421215045.02c94fb0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 21 Apr 2004 22:00:57 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: SASLprep examples 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: In response to IESG comments, I have prepared the following examples to be added to the I-D. Please verify correctness. Also, if you have suggestions for additional (or replacement) examples, please provide offer specifics. -- Kurt 3. Examples The following table provides examples of how various character data is transformed by SASLprep string preparation algorithm. # Input Output Comments - ----- ------ -------- 1 xy xy SOFT HYPHEN mapped to nothing 2 user user no transformation 3 USER USER case preserved, will not match #3 4 xIV output is NFKC 5 Error - prohibited character 6 Error - bidirectional check Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3L8PIiH030169; Wed, 21 Apr 2004 01:25:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3L8PIbj030167; Wed, 21 Apr 2004 01:25:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from bisrv2.bysoft-international.fr (host.68.118.23.62.rev.coltfrance.com [62.23.118.68]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3L8PGHe030128 for ; Wed, 21 Apr 2004 01:25:17 -0700 (PDT) (envelope-from cyril.drouin@bysoft.fr) Received: from CYRILBYSOFT ([192.168.2.200]) by bisrv2.bysoft-international.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JLK6LC2A; Wed, 21 Apr 2004 10:25:51 +0200 From: "Cyril Drouin - Bysoft" To: Subject: Issue with SASL/Postfix/MySQL - Nightmare for 3 DAYS :-( Date: Wed, 21 Apr 2004 10:25:12 +0200 Message-ID: <007e01c4277a$2a7dd700$c802a8c0@CyrilBysoft> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007F_01C4278A.EE06A700" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal 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_007F_01C4278A.EE06A700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have tried for 3 days now to integrate SASL/PostFix/MySQL but I can't = make it. =20 What I have done : =20 - Compile Postfix with the SALS and MySQL support : =20 make -f Makefile.init makefiles 'CCARGS=3D-DHAS_MYSQL -I/home/cyril/mysql/include -DUSE_SASL_AUTH -I/usr/local/include/sasl'=20 'AUXLIBS=3D-L/home/cyril/mysql/lib -lmysqlclient -lz -lm -L/usr/local/lib/sasl2 -lsasl2' - Compile SALS with the MySQL support : =20 env CPPFLAGS=3D"-I/usr/include/mysql" LDFLAGS=3D"-L/usr/lib/mysql -R/usr/lib/mysql" ./configure --enable-sql --with-mysql=3D/usr/lib/mysql - Create the smtpd.conf: =20 sasl_pwcheck_method: auxprop sasl_auxprop_plugin: mysql mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM mysql_user: postfix mysql_passwd: password mysql_hostnames: localhost mysql_database: users mysql_statement: SELECT crypt FROM users WHERE address =3D '%u' mysql_verbose: yes - Change my main.cf to : =20 #Authentification SASL =20 smtpd_sasl_auth_enable =3D yes smtpd_sasl2_auth_enable =3D yes broken_sasl_auth_clients =3D yes smtpd_sasl_local_domain =3D smtpd_sasl_security_options =3D noanonymous smtpd_recipient_restrictions =3D permit_sasl_authenticated, = permit_mynetworks, reject_unauth_destination What I am sure of is : - MySQL and POSTFIX integration is working as I can check the email = through pop3/imap (I am using courier-imap package) - Postfix can send message out =20 Few questions : =20 1/ When I compile sasl, I got an error saying that : =20 checking for mysql_select_db in -lmysqlclient... (cached) no configure: WARNING: MySQL library mysqlclient does not work =20 I can't figure out why I got this warning. I used the same library than = for Mysql 2/ I got nothing in maillog. how can I know if SASL is using Mysql ? = even how can I know if Postfix is using SASL ? =20 Few more details : 1/ Redhat 9 2/ Postfix version 2.0.19 =20 3/ SASL SASL2 2.1.18=20 4/ My password are encrypted in my Database=20 =20 Thanks for your answers..I am getting crazy down here with that. =20 Cyril =20 ------=_NextPart_000_007F_01C4278A.EE06A700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
I have = tried for 3=20 days now to integrate SASL/PostFix/MySQL but I can't make=20 it.
 
What I = have done=20 :
 
- = Compile Postfix=20 with the SALS and MySQL support :
 
make = -f=20 Makefile.init makefiles 'CCARGS=3D-DHAS_MYSQL = -I/home/cyril/mysql/include=20 -DUSE_SASL_AUTH -I/usr/local/include/sasl'
 'AUXLIBS=3D-L/home/cyril/mysql/lib -lmysqlclient -lz -lm=20 -L/usr/local/lib/sasl2 -lsasl2'
- = Compile SALS with=20 the MySQL support :
 
env=20 CPPFLAGS=3D"-I/usr/include/mysql" LDFLAGS=3D"-L/usr/lib/mysql=20 -R/usr/lib/mysql"
./configure --enable-sql=20 --with-mysql=3D/usr/lib/mysql
- = Create the=20 smtpd.conf:
 
sasl_pwcheck_method:=20 auxprop
sasl_auxprop_plugin: mysql
mech_list: PLAIN LOGIN CRAM-MD5 = DIGEST-MD5 NTLM
mysql_user: postfix
mysql_passwd:=20 password
mysql_hostnames:=20 localhost
mysql_database: users
mysql_statement: SELECT crypt FROM = users=20 WHERE address =3D '%u'
mysql_verbose: yes
- = Change my=20 main.cf  to :
 
#Authentification=20 SASL
 
smtpd_sasl_auth_enable =3D yes
smtpd_sasl2_auth_enable =3D=20 yes
broken_sasl_auth_clients =3D yes
smtpd_sasl_local_domain=20 =3D
smtpd_sasl_security_options =3D = noanonymous
smtpd_recipient_restrictions =3D=20 permit_sasl_authenticated, permit_mynetworks,=20 reject_unauth_destination
What I = am sure of is=20 :
- = MySQL and POSTFIX=20 integration is working as I can check the email through pop3/imap (I am = using=20 courier-imap package)
- = Postfix can send=20 message out
 
Few = questions=20 :
 
1/ When I=20 compile sasl, I got an error saying that :
 
checking for=20 mysql_select_db in -lmysqlclient... (cached) no
configure: WARNING: = MySQL=20 library mysqlclient does not work
 
I = can't figure out=20 why I got this warning. I used the same library than for Mysql
2/ I = got nothing in=20 maillog. how can I know if SASL is using Mysql ? even how can I know if = Postfix=20 is using SASL ?
 
Few = more details=20 :
1/ = Redhat=20 9
2/ Postfix=20 version 2.0.19  
3/ SASL SASL2=20 2.1.18 
4/ My password are = encrypted=20 in my Database 
 
Thanks = for your=20 answers..I am getting crazy down here with that.
 
Cyril
 
------=_NextPart_000_007F_01C4278A.EE06A700-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DFpaTX051741; Tue, 13 Apr 2004 08:51:36 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3DFpa9M051740; Tue, 13 Apr 2004 08:51:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-SIXTY-EIGHT.MIT.EDU [18.187.6.113]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DFpa9K051732 for ; Tue, 13 Apr 2004 08:51:36 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id E189A15159C; Tue, 13 Apr 2004 11:51:38 -0400 (EDT) To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Proposed text for adaptive plaintext attacks References: <20040412183716.8C43215159C@konishi-polis.mit.edu> <407BC68A.5070800@isode.com> From: Sam Hartman Date: Tue, 13 Apr 2004 11:51:38 -0400 In-Reply-To: <407BC68A.5070800@isode.com> (Alexey Melnikov's message of "Tue, 13 Apr 2004 11:52:58 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> I personally don't think that the reference to DIGEST-MD5 Alexey> belongs here. This is better be addressed in DIGEST-MD5. I'm OK with dropping it although I'll explain why I put it there. I believe it is important to characterize how valid a security assumption is. In reviewing the security of SASL, I'd like to know both what the security assumptions are and whether these assumptions are actually reasonable. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DAr5KK030389; Tue, 13 Apr 2004 03:53:05 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3DAr527030388; Tue, 13 Apr 2004 03:53:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DAr4Ce030369 for ; Tue, 13 Apr 2004 03:53:04 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 13 Apr 2004 11:53:01 +0100 Message-ID: <407BC68A.5070800@isode.com> Date: Tue, 13 Apr 2004 11:52:58 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Proposed text for adaptive plaintext attacks References: <20040412183716.8C43215159C@konishi-polis.mit.edu> In-Reply-To: <20040412183716.8C43215159C@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: >I propose to replace the following text in section 9: > > Distributed server implementations need to be careful in how they > trust other parties and, in particular, authentication secrets should > only be disclosed to other parties that are trusted to manage and use > those secrets in manner acceptable to disclosing party. It should be > noted that, where those secrets are used to provide data > confidentiality protections, if a third party (other than the > discloser/disclosee) has knowledge of some portion of the protected > information, it can use this knowledge in an attack upon other > portions of the protected information. > > <
on a distributed server implementation. The section also gives some > recommendations about mitigating such attacks.>> > >with the following text: > > Distributed server implementations need to be careful in how they > trust other parties and, in particular, authentication secrets should > only be disclosed to other parties that are trusted to manage and use > those secrets in manner acceptable to disclosing party. > > Applications using SASL assume that SASL security layers providing > confidentiality are secure even when an attacker chooses the text to > be protected by the security layer. Similarly applications assume > that the SASL security layer is secure even if the attacker can > manipulate the ciphertext output of the security layer. With the > exception of the DES modes of the digest-md5 mechanism, all SASL > mechanisms standardized by the IETF are believed to meet these > security assumptions. New SASL mechanisms MUST meet these assumptions. > > > > >Do people feel that explicit text about security considerations of CBC >belong in the base SASL specification? > I personally don't think that the reference to DIGEST-MD5 belongs here. This is better be addressed in DIGEST-MD5. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CKE4aW044063; Mon, 12 Apr 2004 13:14:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CKE4sr044062; Mon, 12 Apr 2004 13:14:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CKE4Qu044056 for ; Mon, 12 Apr 2004 13:14:04 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3CKE8Ms075828 for ; Mon, 12 Apr 2004 20:14:08 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040412130620.04a88b98@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 12 Apr 2004 13:13:49 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-saslprep-08.txt In-Reply-To: <200404121932.PAA08768@ietf.org> References: <200404121932.PAA08768@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: FYI, this revision addresses two issues raised during IETF Last Call. 1) The StringPrep references now points to RFC 3454. This to keep SASLprep from blocking on the StringPrep I-D. 2) The SASL reference was reclassified as Informative as the reader need not read nor understand SASL reference material to implement or make use of SASLprep. Kurt At 12:32 PM 4/12/2004, 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 : SASLprep: Stringprep profile for user names and passwords > Author(s) : K. Zeilenga > Filename : draft-ietf-sasl-saslprep-08.txt > Pages : 6 > Date : 2004-4-12 > >This document describes how to prepare Unicode strings representing > user names and passwords for comparison. The document defines the > 'SASLprep' profile of the 'stringprep' algorithm to be used for both > user names and passwords. This profile is intended to be used by > Simple Authentication and Security Layer (SASL) mechanisms (such as > PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging > simple user names and/or passwords. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-08.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-sasl-saslprep-08.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-sasl-saslprep-08.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-4-12154057.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-sasl-saslprep-08.txt > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CJWSiV037912; Mon, 12 Apr 2004 12:32:28 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CJWSS8037911; Mon, 12 Apr 2004 12:32:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CJWQVj037905 for ; Mon, 12 Apr 2004 12:32:27 -0700 (PDT) (envelope-from rbunch@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 PAA08768; Mon, 12 Apr 2004 15:32:28 -0400 (EDT) Message-Id: <200404121932.PAA08768@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-saslprep-08.txt Date: Mon, 12 Apr 2004 15:32:28 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : SASLprep: Stringprep profile for user names and passwords Author(s) : K. Zeilenga Filename : draft-ietf-sasl-saslprep-08.txt Pages : 6 Date : 2004-4-12 This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the 'SASLprep' profile of the 'stringprep' algorithm to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging simple user names and/or passwords. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-saslprep-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-saslprep-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-12154057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-saslprep-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-saslprep-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-12154057.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CIbDaX031121; Mon, 12 Apr 2004 11:37:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CIbDE7031120; Mon, 12 Apr 2004 11:37:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CIbC1Y031111 for ; Mon, 12 Apr 2004 11:37:13 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 8C43215159C; Mon, 12 Apr 2004 14:37:16 -0400 (EDT) To: ietf-sasl@imc.org Subject: Proposed text for adaptive plaintext attacks Message-Id: <20040412183716.8C43215159C@konishi-polis.mit.edu> Date: Mon, 12 Apr 2004 14:37:16 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I propose to replace the following text in section 9: Distributed server implementations need to be careful in how they trust other parties and, in particular, authentication secrets should only be disclosed to other parties that are trusted to manage and use those secrets in manner acceptable to disclosing party. It should be noted that, where those secrets are used to provide data confidentiality protections, if a third party (other than the discloser/disclosee) has knowledge of some portion of the protected information, it can use this knowledge in an attack upon other portions of the protected information. <
> with the following text: Distributed server implementations need to be careful in how they trust other parties and, in particular, authentication secrets should only be disclosed to other parties that are trusted to manage and use those secrets in manner acceptable to disclosing party. Applications using SASL assume that SASL security layers providing confidentiality are secure even when an attacker chooses the text to be protected by the security layer. Similarly applications assume that the SASL security layer is secure even if the attacker can manipulate the ciphertext output of the security layer. With the exception of the DES modes of the digest-md5 mechanism, all SASL mechanisms standardized by the IETF are believed to meet these security assumptions. New SASL mechanisms MUST meet these assumptions. Do people feel that explicit text about security considerations of CBC belong in the base SASL specification? --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CHiPjr025026; Mon, 12 Apr 2004 10:44:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CHiPhM025025; Mon, 12 Apr 2004 10:44:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CHiORO025016 for ; Mon, 12 Apr 2004 10:44:24 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3CHiSMs073045; Mon, 12 Apr 2004 17:44:28 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040412093816.04a302e8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 12 Apr 2004 10:44:09 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> <6.0.1.1.0.20040410110652.04af8cf8@127.0.0.1> <6.0.1.1.0.20040411121900.04ad5490@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:03 AM 4/12/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> As I noted in my response, we use often use the terms based > Kurt> on "to authenticate" to mean "to login" instead of "to > Kurt> verify". I think the "A"authentication in SASL is commonly > Kurt> used in the "to login" fashion. I like to replace "to login" in the above comment with "to identify". I don't may describing ANONYMOUS mechanism as identifying the user as an anonymous user. I have a problem saying the that the ANONYMOUS verifies the user's identity is anonymous. The latter gives off a number of false impressions. It particular, the latter can be read as implying the ANONYMOUS mechanism is providing verified user identity privacy. > Kurt> rfc2222bis needs to be more clear here, as it is dangerous > Kurt> to say things are "authenticated" when they are not > Kurt> "verified". > >With my security hat on, I have to disagree. Not verified at all is >just one point along the continuum of verification. The security >difference between not verified and poorly verified is not >particularly significant. I agree to your statement as it applies to verification. I would also agree that there is wide continuum of identification. However, I disagree that the terms verification and identification are synonymous. Whether any harm can be caused to inappropriate interchange depends on the particular case. My particular gripe with rfc2222bis is not defining well its terminology and it not terrible self consistent with its use of that terminology. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CG3vCa014178; Mon, 12 Apr 2004 09:03:57 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3CG3vhG014177; Mon, 12 Apr 2004 09:03:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-FIFTY-THREE.MIT.EDU [18.187.6.98]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CG3uuF014170 for ; Mon, 12 Apr 2004 09:03:56 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 6CDF715159C; Mon, 12 Apr 2004 12:03:59 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> <6.0.1.1.0.20040410110652.04af8cf8@127.0.0.1> <6.0.1.1.0.20040411121900.04ad5490@127.0.0.1> From: Sam Hartman Date: Mon, 12 Apr 2004 12:03:59 -0400 In-Reply-To: <6.0.1.1.0.20040411121900.04ad5490@127.0.0.1> (Kurt D. Zeilenga's message of "Sun, 11 Apr 2004 14:00:12 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> As I noted in my response, we use often use the terms based Kurt> on "to authenticate" to mean "to login" instead of "to Kurt> verify". I think the "A"authentication in SASL is commonly Kurt> used in the "to login" fashion. Kurt> rfc2222bis needs to be more clear here, as it is dangerous Kurt> to say things are "authenticated" when they are not Kurt> "verified". With my security hat on, I have to disagree. Not verified at all is just one point along the continuum of verification. The security difference between not verified and poorly verified is not particularly significant. I'm going to try and say less on this issue as making a consensus call is already going to be challenging. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3C2nQ6Y045832; Sun, 11 Apr 2004 19:49:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3C2nQns045831; Sun, 11 Apr 2004 19:49:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3C2nPAh045822 for ; Sun, 11 Apr 2004 19:49:25 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3C2nWMs060390 for ; Mon, 12 Apr 2004 02:49:32 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040411194237.0491d150@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sun, 11 Apr 2004 19:49:14 -0700 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: clarification as to the purpose of ANONYMOUS mechanism 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: In response to recent discussions on this list, I propose to insert the following paragraph between the existing first and second paragraphs of Section 1 of draft-ietf-sasl-anon-xx.txt: Unlike many other SASL mechanisms whose purpose is to authenticate and identify the user to a server, the purpose of this SASL mechanism is to allow the user to gain access to services or resources without requiring the user to establish or otherwise disclose their identity to the server. That is, this mechanism provides an anonymous login method. Comments? Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BL0QmD003224; Sun, 11 Apr 2004 14:00:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3BL0QOO003223; Sun, 11 Apr 2004 14:00:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BL0P9d003217 for ; Sun, 11 Apr 2004 14:00:25 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3BL0UMs055396; Sun, 11 Apr 2004 21:00:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040411121900.04ad5490@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sun, 11 Apr 2004 14:00:12 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication Cc: Sam Hartman , ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> <6.0.1.1.0.20040410110652.04af8cf8@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: As I noted in my response, we use often use the terms based on "to authenticate" to mean "to login" instead of "to verify". I think the "A"authentication in SASL is commonly used in the "to login" fashion. rfc2222bis needs to be more clear here, as it is dangerous to say things are "authenticated" when they are not "verified". And, I think, we should avoid using terms such as "authentication mechanism" when there are reasonable alternatives (such as "SASL mechanism"). At 11:33 AM 4/11/2004, Hallvard B Furuseth wrote: >(I approached this whole thing from the point of view of a user >of a SASL library, who knows SASL but may not be aware that there are >mechanisms that do not provide what the SASL spec might make one assume >it provides.) The SASL specification should be more clear that not all mechanisms verify (or even establish) the user's identity, not all mechanisms pass authorization identity information, not all mechanism support security layers, etc.. That is, the range of function that mechanisms offer can vary widely. And, I think, it very important that to be clear that SASL does not abstract away the differences between mechanisms. Something in the client/server protocol implementation needs to deal with them. Maybe the implementation uses a SASL library that abstracts away some of these differences, but it should be clear something at both the client and the server has to deal with the differences. SASL framework doesn't hide mechanism particulars from protocols. >>> Correction: It needs to say which authentication and authorization IDs >>> it _requests_. Or provides, or whatever is the correct term. Hopefully >>> these IDs will be treated just like IDs from other SASL mechanisms. >>> Or like no ID (unauthenticated), if that's what the mechanism requests. >> >> ANONYMOUS doesn't request nor provide an authentication ID nor an >> authorization ID. > >There has to be _some_ way to say that ANONYMOUS changes the >authentication ID, or requests a change of it, or however you wish to >say that, and what that new ID is, or that the new ID is absent, or >however you wish to say that. By use of the ANONYMOUS mechanism, the client communicates to the server that the user wishes to access the services/resources provided by server on an anonymous basis (e.g., without disclosing its identity to the server). If the server is willing and able, it responds accordingly to the request and takes appropriate actions within its authorization system to grant that access. Note here the separation between what information is communicated by the mechanism and what the server implementation does with that information. Details of how identity information (including lack of knowing the user's identity) is represented by the server are outside the scope of the mechanism specification. >Could you please provide a wording for >that which you will accept, so we can at least talk about how it relates >to the authentication ID? In respect to the mechanism, no authentication ID is communicated. How a server implementation represents that no authentication ID was communicated by the mechanism is its business. >Maybe just some wording to satisfy the SASL >'Profiling requirements' requirement above. Above you called this profiling requirement: A specification of how the authorization identity passed from the client to the server is to be interpreted. This requirement means that protocol (not mechanism) specifications are to define the form used to representation the proxy authorization identity. It should not be viewed as requiring all mechanisms to actually pass a proxy authorization identity information from client-to-server. >> Anyways, I think it sufficient for the mechanism to say what it >> provides (no IDs in the case of ANONYMOUS). How that's used >> in application protocol (or implementations thereof) is simply >> beyond the scope of the mechanism specification. > >Yes. Noted. >>>> It should be obvious that this mechanism does not itself >>>> establish an authentication identity nor transfer an authorization >>>> identity. However, if more clarity is needed, I would suggest >>>> replacing the paragraph: >>>> This mechanism does not provide a security layer. >>>> with: >>>> This mechanism does not establish the identity of the >>>> client (or user) nor the server (or service); does not >>>> support transfer of an authorization identity; nor >>>> provide a security layer. >>> >>> I think either 'It requests anonymous authentication and authorization >>> identities. >> >> I assume It == user here. > >I meant it = mechanism. Though it's on behalf of the user, if that's >what you mean. > >> I'm describing what the mechanism >> establishes and not (in this paragraph) what the user may or >> may not request using this mechanism. > >But 'establishes' is wrong - as you said, how any mechanism affects >authentication and authorization IDs outside of the mechanism is beyond >the scope of that mechanism. I think you are not seeing the separation between what information a mechanism may or may not provide to the client/server, and how that information might be used by the client/server. In the above text, I was referring to what information the mechanism provides to the client/server as opposed to affects which are outside the mechanism. >> Cyrus SASL? > >Yes. But a client and a server which uses the mechanism? I believe you can configure OpenLDAP to make use of the mechanism. Likely Cyrus SASL's own sample client/server may use this mechanism. >Anyway, I kind of hoped someone who already use SASL could tell me, >so I won't have to compile and install stuff just to find out. It's no different than supporting any other mechanism. You need to understand what information the mechanism provide, its semantics, and then map that information into your authorization system. SASL itself doesn't abstract away mechanism differences (but your SASL library might). >The only example I know of is openldap ldapsearch. It does not >treat auth(c/z) ID as trace ID. GOOD. >> It's not to authenticate the entity using the client to the >> client. >> >> This is not to say that clients cannot do that, but the >> security considerations for using SASL in this fashion are >> broad and wide. > >Perhaps they should be discussed in rfc2222bis? Like, in my best Elmer Fudd voice, "be very, very careful" :-) >>> and then grant access to >>> something on the client side depending on whether or not authentication >>> succeeds. >> >> Such a client would need to treat ANONYMOUS as not establishing >> the user's entity. Here, at least, the client can just disallow >> the mechanism. A client which uses PLAIN, CRAM-MD5, etc., for >> such has it far worse. They need to know which user names >> have widely known passwords or user names are granted access >> regardless of what password is provided. How many PLAIN >> deployments out there accept any password for "anonymous"? > >Do you mean such things come with the default SASL setup with some >implementations? That sounds scary enough that it might be an idea to >warn about it in rfc2222bis. I think we need a brief warning. SASL purpose is to "login" the client to the server. It's not designed "login" the user to the client. What the server might find acceptable, may not be acceptable to the client. >Client's using SASL for the purposes of granting access to services/resources >at the client should be "very, very careful" not to make invalid assumptions >about the success (or failure) of a SASL mechanism exchange. >All that any SASL mechanism authenticates is that the client provided >sufficient credentials to authenticate in the manner it did. Which is >none at all, in the ANONYMOUS case. The administrator who allowed >that authentication is the one who knows what it means that someone >authenticated that way, and what access to grant. Noting that you are using the "to authenticate" (and variants) to mean "to login", I would have to agree with this statement. In particular, I agree that client does not provide any credentials when using the ANONYMOUS mechanism. This has been one of my points through this discussion. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BIsf8B084826; Sun, 11 Apr 2004 11:54:41 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3BIsfR3084824; Sun, 11 Apr 2004 11:54:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BIseVW084811 for ; Sun, 11 Apr 2004 11:54:40 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1BCk6L-0005QB-64 for ietf-sasl@imc.org; Sun, 11 Apr 2004 20:54:41 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.30) id 1BCk6I-0000sg-6j; Sun, 11 Apr 2004 20:54:38 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BCk6H-0006PO-00; Sun, 11 Apr 2004 20:54:37 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: rfc2222bis: authentication identity Date: Sun, 11 Apr 2004 20:54:37 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: rfc2222bis has added the concept of an authentication identity since rfc2222. Is this identity only a parameter to the SASL authentication process, and can be discarded after SASL authentication is complete? Or is it also part of the connecton's authorization state after SASL authentication? If so, what for? Could you clarify that in the draft? -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BIf5H1083134; Sun, 11 Apr 2004 11:41:05 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3BIf55C083133; Sun, 11 Apr 2004 11:41:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BIf4nt083118 for ; Sun, 11 Apr 2004 11:41:05 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1BCjt9-00035M-GK; Sun, 11 Apr 2004 20:41:03 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.30) id 1BCjt3-00085A-11; Sun, 11 Apr 2004 20:40:57 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BCjt2-0006Mp-00; Sun, 11 Apr 2004 20:40:56 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Sam Hartman , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> <6.0.1.1.0.20040410110652.04af8cf8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sun, 11 Apr 2004 20:40:56 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Grumble. Read through a message two times before sending, then discover a mistake just after sending:-( I wrote: > 4. Profiling requirements > 5. A specification of how the authorization identity passed from the > client to the server is to be interpreted. > > [ANONYMOUS] does not fulfill that requirement. I meant, [ANONYMOUS] as currently described, or as you describe it, does not provide such an authorization identity for the protocol to interpret. Even if it is not 'passed from the client', the protocol spec needs to get an authorization identity from the SASL mechanism in order to fulfill this requirement. -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BIXskd081887; Sun, 11 Apr 2004 11:33:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3BIXsM8081886; Sun, 11 Apr 2004 11:33:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BIXqjQ081860 for ; Sun, 11 Apr 2004 11:33:53 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1BCjmA-0001tf-SQ; Sun, 11 Apr 2004 20:33:50 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.30) id 1BCjm6-0007L6-LP; Sun, 11 Apr 2004 20:33:46 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BCjm5-0006MU-00; Sun, 11 Apr 2004 20:33:45 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Sam Hartman , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication In-Reply-To: <6.0.1.1.0.20040410110652.04af8cf8@127.0.0.1> References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> <6.0.1.1.0.20040410110652.04af8cf8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sun, 11 Apr 2004 20:33:45 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >At 10:33 AM 4/10/2004, Hallvard B Furuseth wrote: >>Kurt D. Zeilenga writes: >>>At 07:53 AM 4/10/2004, Hallvard B Furuseth wrote: >>>>Kurt D. Zeilenga writes: >>>>> The anonymous mechanism doesn't provide any >>>>> authentication service. (Not all SASL mechanisms provide >>>>> authentication services.) >>>> >>>> That's not what rfc2222bis says. It describes SASL mechanisms as >>>> authentication mechanisms, and describes everything about these in >>>> terms of authentication. >>> >>> Which is a problem. rfc2222bis should be likely use more >>> generic terms, like "SASL mechanism" when referring to a >>> SASL mechanism. >> >> rfc2222 does the same thing. > > RFC 2222 only once used the term "authentication mechanism". > This was in the security consideration section, Sorry, I should have said I looked for 'authentication' and 'authorization' in general. In particular the term 'authentication protocol exchange' is recurring. E.g.: 3. Introduction and Overview The Simple Authentication and Security Layer (SASL) is a method for adding authentication support to connection-based protocols. (...) If a server supports the requested mechanism, it initiates an authentication protocol exchange. (...) During the authentication protocol exchange, the mechanism performs authentication, transmits an authorization identity (...) 5.3. Multiple authentications 4. Profiling requirements 5. A specification of how the authorization identity passed from the client to the server is to be interpreted. [ANONYMOUS] does not fulfill that requirement. >> Did it incorrectly describe existing >> implementations, or were mechanisms like ANONYMOUS added later? > > Often one describes features of protocols based upon what > purpose they generally serve even though they might not > always be used for that purpose. See say "security layer" > even though the feature (say data compression) may not used > to provide non-security layer . > > The fact that we name these features as we do, it should be > made clear that they do not always provide the function the > names imply. This should be made clear in RFC 2222. True. (I approached this whole thing from the point of view of a user of a SASL library, who knows SASL but may not be aware that there are mechanisms that do not provide what the SASL spec might make one assume it provides.) >> Correction: It needs to say which authentication and authorization IDs >> it _requests_. Or provides, or whatever is the correct term. Hopefully >> these IDs will be treated just like IDs from other SASL mechanisms. >> Or like no ID (unauthenticated), if that's what the mechanism requests. > > ANONYMOUS doesn't request nor provide an authentication ID nor an > authorization ID. There has to be _some_ way to say that ANONYMOUS changes the authentication ID, or requests a change of it, or however you wish to say that, and what that new ID is, or that the new ID is absent, or however you wish to say that. Could you please provide a wording for that which you will accept, so we can at least talk about how it relates to the authentication ID? Maybe just some wording to satisfy the SASL 'Profiling requirements' requirement above. I'll hold off replying to part of your message (if a reply to the rest still seems relevant) until then. > Note that there could be other mechanisms would also do not > provide such IDs to the server. See the section from '4. Profiling requirements' quoted above. > Consider a mechanism which > only authenticated the server to the client. Hmm - I suppose the mechanism could specify that the authentication ID is the one which was already in use. > Anyways, I think it sufficient for the mechanism to say what it > provides (no IDs in the case of ANONYMOUS). How that's used > in application protocol (or implementations thereof) is simply > beyond the scope of the mechanism specification. Yes. >>> It should be obvious that this mechanism does not itself >>> establish an authentication identity nor transfer an authorization >>> identity. However, if more clarity is needed, I would suggest >>> replacing the paragraph: >>> This mechanism does not provide a security layer. >>> with: >>> This mechanism does not establish the identity of the >>> client (or user) nor the server (or service); does not >>> support transfer of an authorization identity; nor >>> provide a security layer. >> >> I think either 'It requests anonymous authentication and authorization >> identities. > > I assume It == user here. I meant it = mechanism. Though it's on behalf of the user, if that's what you mean. > I'm describing what the mechanism > establishes and not (in this paragraph) what the user may or > may not request using this mechanism. But 'establishes' is wrong - as you said, how any mechanism affects authentication and authorization IDs outside of the mechanism is beyond the scope of that mechanism. >> How to treat the anonymous ID is up to the protocol or >> implementation.', or 'It does not affect the authentication and >> authorization identities'. > > The latter is especially dangerous Well, I hoped that was not what it does. Your recent messages in this thread just made me wonder if it did. >>>> Also, I now wonder how clients typically implement ANONYMOUS. If they >>>> support several SASL mechanisms, do clients expect the identity to send >>>> with ANONYMOUS in the same command line option or whatever which they >>>> use for the authentication IDs for other SASL mechanisms, or do they use >>>> some other field? >>> >>> I suggest you look at some existing implementations. >> >> I don't know where to find any... > > Cyrus SASL? Yes. But a client and a server which uses the mechanism? Anyway, I kind of hoped someone who already use SASL could tell me, so I won't have to compile and install stuff just to find out. The only example I know of is openldap ldapsearch. It does not treat auth(c/z) ID as trace ID. >>> But >>> I would hope the user would not be asked or expected to >>> provide their credentials (or portions of their credentials) >>> when using this mechanism. >> >> If you mean e.g. a password, I agree. > > I mean credentials. Credentials may include many things... > and generally (but not necessarily) includes a representation of > the identity they are used to establish. For instance, in > PLAIN, the credentials include both a representation of > the user's identity and a password. The user has to know > both to gain access as that user. OK. >> However, I was thinking of >> clients that authenticate to the server > > Who are they authenticating? Themselves or whatever entity is > using the client? SASL general function is to authenticate > the client (or entity which is using a client) to the server. Sure. > It's not to authenticate the entity using the client to the > client. > > This is not to say that clients cannot do that, but the > security considerations for using SASL in this fashion are > broad and wide. Perhaps they should be discussed in rfc2222bis? >> and then grant access to >> something on the client side depending on whether or not authentication >> succeeds. > > Such a client would need to treat ANONYMOUS as not establishing > the user's entity. Here, at least, the client can just disallow > the mechanism. A client which uses PLAIN, CRAM-MD5, etc., for > such has it far worse. They need to know which user names > have widely known passwords or user names are granted access > regardless of what password is provided. How many PLAIN > deployments out there accept any password for "anonymous"? Do you mean such things come with the default SASL setup with some implementations? That sounds scary enough that it might be an idea to warn about it in rfc2222bis. Otherwise I don't see the problem. The client will authenticate against a server which it knows is set up to authenticate the possible users of that clients. Other user names will not be recognized. Except ANONYMOUS "user names", if the client treats the trace information sent with ANONYMOUS the same way it treats user names for other mechanisms. Anyway, I simply wondered if clients do that. I hope not. >> Or it could refuse the user to specify the ANONYMOUS >> mechanism, of course. > > If a client is going to use mechanisms to authorize users > to access services AT the client, then it needs to understand > not only the services provided by the mechanism, but > protocol/implementation/deployment details of the server > it using in support of user authentication to the client. OK. >>> But it should be clear that anonymous methods in LDAP, FTP, >>> and elsewhere are not authenticating the user's identity. >> >> In LDAP it does not authenticate. In FTP it does, to the server. The >> anonymous user has the access which the filesystem grants to a specific >> user on the filesystem. > > The problem with your statement, in my opinion, is the > implication that the user's identity seeking anonymous > access has THEIR identity authenticated. (...) I don't think so. Users of shared accounts don't authenticate as THEIR identities either. My nearest public library has the public account's username and password taped to the public computers, so people can reboot the beasts without running to a librarian for help. That's not the user's identity either. All that any SASL mechanism authenticates is that the client provided sufficient credentials to authenticate in the manner it did. Which is none at all, in the ANONYMOUS case. The administrator who allowed that authentication is the one who knows what it means that someone authenticated that way, and what access to grant. -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3B0nE4q000514; Sat, 10 Apr 2004 17:49:14 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3B0nERJ000513; Sat, 10 Apr 2004 17:49:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3B0nELb000505 for ; Sat, 10 Apr 2004 17:49:14 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3B0nJMs040892; Sun, 11 Apr 2004 00:49:19 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040410145813.0526eb00@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 10 Apr 2004 17:49:02 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410103203.04ae46b8@127.0.0.1> <6.0.1.1.0.20040410130528.04b19dd8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 01:58 PM 4/10/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> This is quite different than saying that anonymous users > Kurt> have established (authenticated) THEIR identity in the > Kurt> service. > >> I don't see the difference. IN both cases, the identity (or > >> non-identity) you are authorized as establishes your privileges > >> in the system. > > Kurt> The difference is that, when using ANONYMOUS, users don't > Kurt> establish THEIR identity, they establish some factor in the > Kurt> server which allows them access without requiring that they > Kurt> establish THEIR identity. >That sort of depends on your model for identity. I think it depends more on who is establishing what, and by what means. When ANONYMOUS is being used, the USER is not required to establish THEIR identity. Whether or not the server-side mechanism implementation represents, or how it represents, to the server-side protocol implementation that the USER has requested access be granted on an anonymous-basis (e.g, with requiring the USER to establish THEIR identity), as well as how that server-side protocol implementation might then use this information in authorization decisions is a separate (and separable) issue. >It seems completely reasonable to say something along the following >lines. Anonymous establishes the anonymous identity with no >confidence in that identity. IP address-based authentication >establishes an identity based on the IP address with low confidence in >that identity. AUthentication by assertion establishes the asserted >identity with low confidence in that assertion. External >authentication with a client TLS certificate establishes the >SubjectName of the certificate as the identity with reasonably high >confidence in that identity. In the three non-anonymous examples you provide, each requires the user to disclose its identity. In the anonymous case, the user is not required to disclose information its identity (though the user might be identifiable otherwise). So, I think, your analogy is a bit flawed. But, what concerns me is implication that the ANONYMOUS mechanism establishes through the exchange an identity representation that refers users who have not established their entity. I find that implication misleading and confusing. If such a representation is to be established, it's being established by, for, and within server implementation. That is, such is being manufactured outside of the mechanism exchange as defined by this specification. >Now in this working group we don't really care about the properties of >the identity established by anonymous authentication. For example, we >don't care if the identities resulting from two different anonymous >authentications compare to be equal or are guaranteed to be distinct. I agree. >Again, I think we are arguing about isomorphic models. >Conceptually,believe there is an identity and some factor indicating >whether the identity has been established. I believe that one class >of identity is the unestablished identity. > >So why am I arguing over isomorphisms? I think we're arguing over whether "to authenticate" means "to verify" or whether it means "to login (with our without verification)". SASL mechanisms are login mechanisms: some provide authenticated login capabilities, some provide anonymous login capabilities. >Unfortunately, the particular >conceptual model we use seems to appear at least in part in the text >of the base specification. I think the base specification has problems in three areas (that impact this discussion): 1) The base specification does not use terms consistently, 2) The base specification doesn't always define the terms it uses, and 3) The base specification is not clear that as to the range of function that a SASL mechanism can provide. >I believe that treating everything as >authentication will make that base specification easier to understand >at the cost of hiding conceptual complexity in anonymous. To a certain degree I agree that some of the conceptual complexity can be hidden in ANONYMOUS, excepting the base specification needs to be clear that not everything fits the easier to understand model which the base specification puts forth. Anyways, in regards to the ANONYMOUS specification, I'm going to offer a slightly revised intro text for the WG to consider here shortly. However, I think the base specification needs work to be more easily understood. For instance, 2222bis uses of the terms: SASL authentication mechanism, SASL mechanism, authentication mechanism, and mechanism generally in an interchangeable fashion. However, in some uses in the document where it obvious that they are not interchangeable. This confuses all the uses which the author used them interchangeable, leaving a mess for the reader to decipher. I think it would be far better if we would consistently use the term "SASL mechanism" (and "mechanism" only where it is clear we're referring to a SASL mechanism) as RFC 2222 generally did. And I think we should be more clear as to what functions SASL mechanisms generally provide (and how some may offer vastly different functions than other mechanisms). >I may be wrong; this may confuse people to much and be important to change. At the moment, some readers of 2222bis are going to be confused as some of the terminology is new and different than what was used in RFC 2222, BUT the largest problem is that much of the terminology (new and old) is not well-defined and/or not used consistently. >I'm also arguing to show that this is not an editorial correction to >the base specification. You're proposing changing how we think about >SASL or at least expanding an area of thought about SASL where our >previous thinking was vague. I don't think I am arguing that we change how we think about SASL. I am mostly arguing that we clean up our terminology. And I am objecting to use of language which is not consistent with our terminology. Of course, "what is our terminology" is a bit of an open question given that 2222bis does well-define our terminology. >Making that change is a reasonable thing >for the working group to do, but it does need to meet a slightly >higher bar than an editorialclarification. Inconsistent use of poorly-defined terminology is, I think, not just an "editorial clarification" concern, it's a general technical quality concern. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AKwIvq081233; Sat, 10 Apr 2004 13:58:18 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AKwI98081232; Sat, 10 Apr 2004 13:58:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-FIFTY-THREE.MIT.EDU [18.187.6.98]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AKwGhv081226 for ; Sat, 10 Apr 2004 13:58:16 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 7218415159C; Sat, 10 Apr 2004 16:58:21 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410103203.04ae46b8@127.0.0.1> <6.0.1.1.0.20040410130528.04b19dd8@127.0.0.1> From: Sam Hartman Date: Sat, 10 Apr 2004 16:58:21 -0400 In-Reply-To: <6.0.1.1.0.20040410130528.04b19dd8@127.0.0.1> (Kurt D. Zeilenga's message of "Sat, 10 Apr 2004 13:25:22 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> This is quite different than saying that anonymous users Kurt> have established (authenticated) THEIR identity in the Kurt> service. >> I don't see the difference. IN both cases, the identity (or >> non-identity) you are authorized as establishes your privileges >> in the system. Kurt> The difference is that, when using ANONYMOUS, users don't Kurt> establish THEIR identity, they establish some factor in the Kurt> server which allows them access without requiring that they Kurt> establish THEIR identity. That sort of depends on your model for identity. It seems completely reasonable to say something along the following lines. Anonymous establishes the anonymous identity with no confidence in that identity. IP address-based authentication establishes an identity based on the IP address with low confidence in that identity. AUthentication by assertion establishes the asserted identity with low confidence in that assertion. External authentication with a client TLS certificate establishes the SubjectName of the certificate as the identity with reasonably high confidence in that identity. Now in this working group we don't really care about the properties of the identity established by anonymous authentication. For example, we don't care if the identities resulting from two different anonymous authentications compare to be equal or are guaranteed to be distinct. You probably want one of the two to be true and for most purposes you don't care which. Again, I think we are arguing about isomorphic models. Conceptually,believe there is an identity and some factor indicating whether the identity has been established. I believe that one class of identity is the unestablished identity. So why am I arguing over isomorphisms? Unfortunately, the particular conceptual model we use seems to appear at least in part in the text of the base specification. I believe that treating everything as authentication will make that base specification easier to understand at the cost of hiding conceptual complexity in anonymous. I may be wrong; this may confuse people to much and be important to change. I'm also arguing to show that this is not an editorial correction to the base specification. You're proposing changing how we think about SASL or at least expanding an area of thought about SASL where our previous thinking was vague. Making that change is a reasonable thing for the working group to do, but it does need to meet a slightly higher bar than an editorialclarification. Kurt> Sure, a system can associate some Kurt> identity representation to all users which have not Kurt> established THEIR identity, but that imply the user has Kurt> established THEIR identity. Kurt> And, I would hope, we can agree on whether or not the system Kurt> does associate some identity representation to all users Kurt> which not established THEIR identities or not, or what that Kurt> identity representation might be, is completely beyond the Kurt> scope of this mechanism. Just as what authorization Kurt> identity representation the system might associate with an Kurt> user who DOES establish their identity is beyond the scope Kurt> of the mechanism. Agreed. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AKlKAh080090; Sat, 10 Apr 2004 13:47:20 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AKlKSi080089; Sat, 10 Apr 2004 13:47:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AKlKEk080083 for ; Sat, 10 Apr 2004 13:47:20 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3AKlOMs036861; Sat, 10 Apr 2004 20:47:24 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040410134518.04ae6468@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 10 Apr 2004 13:47:08 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication [corrected] Cc: Hallvard B Furuseth , ietf-sasl@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I need to slow down... At 11:09 AM 4/10/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> At 09:58 AM 4/10/2004, Sam Hartman wrote: > Hallvard> See above. Also, Sam's statement that all ANONYMOUS > Hallvard> users have the _same_ authorization ID, not _no_ > Hallvard> authorization ID. Which made me realize that anonymous > Hallvard> auth is not a SASL term, but one I'm used to from LDAP, > Hallvard> where it means the same as no auth. OTOH, FTP (at least > Hallvard> on Unix) implements anonymous auth the way Sam > Hallvard> describes: A specific user on the server's system, with > Hallvard> limited access. > >> I think my statement is still generally true. It may happen > >> that the authorization ID of anonymous users is also the same > >> as the authorization ID of users who have engaged in no > >> authentication exchange. > > Kurt> But here you are talking about some authorization ID which > Kurt> the service merely associates with the state of being > Kurt> anonymous (having an unknown or concealed identity). > >Agree.d > > Kurt> This > Kurt> is quite different than saying that anonymous users have > Kurt> established (authenticated) THEIR identity in the service. > >I don't see the difference. IN both cases, the identity (or >non-identity) you are authorized as establishes your privileges in the >system. The difference is that, when using ANONYMOUS, users don't establish THEIR identity, they establish some factor in the server which allows them access without requiring that they establish THEIR identity. Sure, a system can associate some identity representation to all users which have not established THEIR identity, but that DOES NOT imply the user has established THEIR identity. And, I would hope, we can agree on whether or not the system does associate some identity representation to all users which not established THEIR identities or not, or what that identity representation might be, is completely beyond the scope of this mechanism. Just as what authorization identity representation the system might associate with an user who DOES establish their identity is beyond the scope of the mechanism. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AKPY2e077843; Sat, 10 Apr 2004 13:25:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AKPYFZ077842; Sat, 10 Apr 2004 13:25:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AKPXSG077836 for ; Sat, 10 Apr 2004 13:25:34 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3AKPcMs036626; Sat, 10 Apr 2004 20:25:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040410130528.04b19dd8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 10 Apr 2004 13:25:22 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410103203.04ae46b8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:09 AM 4/10/2004, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > Kurt> At 09:58 AM 4/10/2004, Sam Hartman wrote: > Hallvard> See above. Also, Sam's statement that all ANONYMOUS > Hallvard> users have the _same_ authorization ID, not _no_ > Hallvard> authorization ID. Which made me realize that anonymous > Hallvard> auth is not a SASL term, but one I'm used to from LDAP, > Hallvard> where it means the same as no auth. OTOH, FTP (at least > Hallvard> on Unix) implements anonymous auth the way Sam > Hallvard> describes: A specific user on the server's system, with > Hallvard> limited access. > >> I think my statement is still generally true. It may happen > >> that the authorization ID of anonymous users is also the same > >> as the authorization ID of users who have engaged in no > >> authentication exchange. > > Kurt> But here you are talking about some authorization ID which > Kurt> the service merely associates with the state of being > Kurt> anonymous (having an unknown or concealed identity). > >Agree.d > > Kurt> This > Kurt> is quite different than saying that anonymous users have > Kurt> established (authenticated) THEIR identity in the service. > >I don't see the difference. IN both cases, the identity (or >non-identity) you are authorized as establishes your privileges in the >system. The difference is that, when using ANONYMOUS, users don't establish THEIR identity, they establish some factor in the server which allows them access without requiring that they establish THEIR identity. Sure, a system can associate some identity representation to all users which have not established THEIR identity, but that imply the user has established THEIR identity. And, I would hope, we can agree on whether or not the system does associate some identity representation to all users which not established THEIR identities or not, or what that identity representation might be, is completely beyond the scope of this mechanism. Just as what authorization identity representation the system might associate with an user who DOES establish their identity is beyond the scope of the mechanism. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AK46Zf076083; Sat, 10 Apr 2004 13:04:06 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AK45GE076082; Sat, 10 Apr 2004 13:04:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AK44DP076076 for ; Sat, 10 Apr 2004 13:04:04 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3AK49Ms036300; Sat, 10 Apr 2004 20:04:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040410110652.04af8cf8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 10 Apr 2004 13:03:52 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication Cc: Sam Hartman , ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@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:33 AM 4/10/2004, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>At 07:53 AM 4/10/2004, Hallvard B Furuseth wrote: >>>Kurt D. Zeilenga writes: >>>>At 09:41 AM 4/7/2004, Sam Hartman wrote: >>>>>>>>>> "Hallvard" == Hallvard B Furuseth writes: >>>>> >>>> The anonymous mechanism doesn't provide any >>>> authentication service. (Not all SASL mechanisms provide >>>> authentication services.) >>> >>> That's not what rfc2222bis says. It describes SASL mechanisms as >>> authentication mechanisms, and describes everything about these in >>> terms of authentication. >> >> Which is a problem. rfc2222bis should be likely use more >> generic terms, like "SASL mechanism" when referring to a >> SASL mechanism. > >rfc2222 does the same thing. RFC 2222 only once used the term "authentication mechanism". This was in the security consideration section, when referring to relative strengths of various mechanisms. It failed to distinguish that some mechanisms do not provide authentication services. That should be corrected. Everywhere else in RFC 2222, RFC 2222 used generic terms. >Did it incorrectly describe existing >implementations, or were mechanisms like ANONYMOUS added later? Often one describes features of protocols based upon what purpose they generally serve even though they might not always be used for that purpose. See say "security layer" even though the feature (say data compression) may not used to provide non-security layer . The fact that we name these features as we do, it should be made clear that they do not always provide the function the names imply. This should be made clear in RFC 2222. >>> One which doesn't authenticate, from what you say. >> >> I would hope it obvious that ANONYMOUS does not authenticate anything. > >If it affects the authorization or authentication IDs, it... well, yes. >un-authenticates, I suppose. I prefer to say that the ANONYMOUS mechanism, like all mechanisms, is used to establish a new authorization state which displaces the previous authorization state. In particular, ANONYMOUS is used to establish an anonymous authorization state. That is, the purpose of ANONYMOUS is to provide access of that of a user without requiring the user to establish their identity. >If it doesn't, it seems to violate rfc2222 and rfc2222bis. I think ANONYMOUS is fairly consistent with RFC 2222 and 2222bis. I think 2222bis needs some further clarification here and there. >>> However, I think the ANONYMOUS draft does need to say explicitly how it >>> affects the authentication and authorization IDs. >> >> How any mechanism affects authentication and authorization IDs >> outside of the mechanism is beyond the scope of that mechanism. > >Beyond the scope of any mechanism, I think. > >Correction: It needs to say which authentication and authorization IDs >it _requests_. Or provides, or whatever is the correct term. Hopefully >these IDs will be treated just like IDs from other SASL mechanisms. >Or like no ID (unauthenticated), if that's what the mechanism requests. ANONYMOUS doesn't request nor provide an authentication ID nor an authorization ID. Note that there could be other mechanisms would also do not provide such IDs to the server. Consider a mechanism which only authenticated the server to the client. Anyways, I think it sufficient for the mechanism to say what it provides (no IDs in the case of ANONYMOUS). How that's used in application protocol (or implementations thereof) is simply beyond the scope of the mechanism specification. >> It should be obvious that this mechanism does not itself >> establish an authentication identity nor transfer an authorization >> identity. However, if more clarity is needed, I would suggest >> replacing the paragraph: >> This mechanism does not provide a security layer. >> with: >> This mechanism does not establish the identity of the >> client (or user) nor the server (or service); does not >> support transfer of an authorization identity; nor >> provide a security layer. > >I think either 'It requests anonymous authentication and authorization >identities. I assume It == user here. I'm describing what the mechanism establishes and not (in this paragraph) what the user may or may not request using this mechanism. >How to treat the anonymous ID is up to the protocol or >implementation.', or 'It does not affect the authentication and >authorization identities'. The latter is especially dangerous because confusing between whether we're talking about the identity established by the user through authentication, and some identity value which represents the user has not established THEIR identity through authentication. >>> Also, I now wonder how clients typically implement ANONYMOUS. If they >>> support several SASL mechanisms, do clients expect the identity to send >>> with ANONYMOUS in the same command line option or whatever which they >>> use for the authentication IDs for other SASL mechanisms, or do they use >>> some other field? >> >> I suggest you look at some existing implementations. > >I don't know where to find any... Cyrus SASL? >> But >> I would hope the user would not be asked or expected to >> provide their credentials (or portions of their credentials) >> when using this mechanism. > >If you mean e.g. a password, I agree. I mean credentials. Credentials may include many things... and generally (but not necessarily) includes a representation of the identity they are used to establish. For instance, in PLAIN, the credentials include both a representation of the user's identity and a password. The user has to know both to gain access as that user. >However, I was thinking of >clients that authenticate to the server Who are they authenticating? Themselves or whatever entity is using the client? SASL general function is to authenticate the client (or entity which is using a client) to the server. It's not to authenticate the entity using the client to the client. This is not to say that clients cannot do that, but the security considerations for using SASL in this fashion are broad and wide. >and then grant access to >something on the client side depending on whether or not authentication >succeeds. Such a client would need to treat ANONYMOUS as not establishing the user's entity. Here, at least, the client can just disallow the mechanism. A client which uses PLAIN, CRAM-MD5, etc., for such has it far worse. They need to know which user names have widely known passwords or user names are granted access regardless of what password is provided. How many PLAIN deployments out there accept any password for "anonymous"? >Such a client must not treat the ID sent with ANONYMOUS as an >authentication ID. Whether the trace information provided by the client has any semantical value to the client is beyond the scope of the mechanism. The mechanism is quite clear that the email address, if provided, as no semantical value to the mechanism and should only be used by the server for trace purposes. >Or it could refuse the user to specify the ANONYMOUS >mechanism, of course. If a client is going to use mechanisms to authorize users to access services AT the client, then it needs to understand not only the services provided by the mechanism, but protocol/implementation/deployment details of the server it using in support of user authentication to the client. >>>> I also find it odd the implication (in Hallvard's comments) that an >>>> anonymous user has an established identity. I take the view that an >>>> anonymous user is one whose's identity has not been established >>> >>> See above. Also, Sam's statement that all ANONYMOUS users have the >>> _same_ authorization ID, not _no_ authorization ID. >> >> I think Sam's statement is problematic in that implies that the >> mechanism is establishing or authenticating the user's identity. >> The server might be associating an identity with anonymous >> users, but the server certainly is not establishing >> or authenticating the user's identity. > >I don't see why not. The user just doesn't have anything to do with any >information sent in the authentication requests. Instead the user is >built into the mechanism itself. Once it is established, it has the >access which the server grants that user, just like with authenticated >users. The distinction is wether or not the mechanism is authenticating the user's identity or whether the server-side implementation of the mechanism is merely associating some identity representation that indicates that the user's identity has not been established by the mechanism. That latter is an implementation detail. >>> Which made me realize that anonymous auth is not a SASL term, but one >>> I'm used to from LDAP, where it means the same as no auth. OTOH, FTP >>> (at least on Unix) implements anonymous auth the way Sam describes: A >>> specific user on the server's system, with limited access. >> >> But it should be clear that anonymous methods in LDAP, FTP, >> and elsewhere are not authenticating the user's identity. > >In LDAP it does not authenticate. In FTP it does, to the server. The >anonymous user has the access which the filesystem grants to a specific >user on the filesystem. The problem with your statement, in my opinion, is the implication that the user's identity seeking anonymous access has THEIR identity authenticated. No, the user seeking anonymous access is asserting a well-known account name which grants access to anyone and everyone regardless of what password is provided. So, while one is going through a login process, it is an anonymous login process. That is, the user is not required to provide THEIR credentials for authentication. They are granted access without authentication of who THEY are. It should be clear in ANONYMOUS that there is no well-known identity representation transferred to obtain anonymous access nor is any particular identity representation implies to have been transferred to the server by use of ANONYMOUS. >>>> (or is concealed). >>> >>> Oh dear. I wish you hadn't added that. >> >> RFC 2828: >> $ anonymous >> (I) The condition of having a name that is unknown or concealed. >> >>> Which identity do you mean? >> >> The identity of the user (or a user). >> >>> Authentication or authorization identity, after all? >> >> Both, as they both refer to identities of users. >> >>> And who is it concealed from? The server, or other users? >> >> In this case, they are concealed from (at least) the server. > >Uh... An authorization identity concealed to the server is not >a concept I can quite wrap my head around. The server grants >access based on some specific authorization identity. Or lack thereof. But more to the point is that the authorization identity it uses is something it constructs (possible directly from information provided in the exchange). A user can be said to be anonymous to the server if the identity of THAT user (a particular user) is not known to the server. That is, the identity of the user has been concealed by the user, the client, and the choice of mechanism. Hence, where a server might associate some special authorization identity representation to all users who have not established their identity as implying that the special identity representation used by the server is authenticated or identifies the particular user. >>>> Hallvard: I'm not sure what your question is (in your last >>>> response). If your asking whether SASL itself or the >>>> ANONYMOUS mechanism defines a particular identity representation >>>> to refer to anonymous users (users which have no established >>>> identity), I think the answer is no. If your asking whether >>>> SASL or ANONYMOUS explicitly provides a facility for a user >>>> to authenticate oneself and assume the authorization of an >>>> anonymous user, I think the answer is no. >>> >>> Almost... I'm wondering if SASL even allows an authentication >>> mechanism to revert the authentication and authorization IDs back >>> to unauthenticated - that is, the same state as before the first >>> authentication. >> >> SASL doesn't support "revert", it supports moving to a new >> authorization state. > >Replace "revert" back to "unauthenticated", then. That would make even less sense: unauthenticate the authentication ID? >> That new authorization state could be an anonymous one (one where the >> identity of the user is not established (authenticated)). > >I can't find any place in rfc2222bis which says so. Where? As I said before, RFC 2222bis needs work here. A number of the clarifications added to RFC 2222bis are causing confusion. Those clarifications need refinement. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AI9TgW063801; Sat, 10 Apr 2004 11:09:30 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AI9Tih063800; Sat, 10 Apr 2004 11:09:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-FIFTY-THREE.MIT.EDU [18.187.6.98]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AI9TMw063794 for ; Sat, 10 Apr 2004 11:09:29 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 59F8815159C; Sat, 10 Apr 2004 14:09:29 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410103203.04ae46b8@127.0.0.1> From: Sam Hartman Date: Sat, 10 Apr 2004 14:09:29 -0400 In-Reply-To: <6.0.1.1.0.20040410103203.04ae46b8@127.0.0.1> (Kurt D. Zeilenga's message of "Sat, 10 Apr 2004 10:38:45 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> At 09:58 AM 4/10/2004, Sam Hartman wrote: Hallvard> See above. Also, Sam's statement that all ANONYMOUS Hallvard> users have the _same_ authorization ID, not _no_ Hallvard> authorization ID. Which made me realize that anonymous Hallvard> auth is not a SASL term, but one I'm used to from LDAP, Hallvard> where it means the same as no auth. OTOH, FTP (at least Hallvard> on Unix) implements anonymous auth the way Sam Hallvard> describes: A specific user on the server's system, with Hallvard> limited access. >> I think my statement is still generally true. It may happen >> that the authorization ID of anonymous users is also the same >> as the authorization ID of users who have engaged in no >> authentication exchange. Kurt> But here you are talking about some authorization ID which Kurt> the service merely associates with the state of being Kurt> anonymous (having an unknown or concealed identity). Agree.d Kurt> This Kurt> is quite different than saying that anonymous users have Kurt> established (authenticated) THEIR identity in the service. I don't see the difference. IN both cases, the identity (or non-identity) you are authorized as establishes your privileges in the system. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AHcxXk060731; Sat, 10 Apr 2004 10:38:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AHcxx2060730; Sat, 10 Apr 2004 10:38:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AHcwvG060723 for ; Sat, 10 Apr 2004 10:38:58 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3AHd2Ms034086; Sat, 10 Apr 2004 17:39:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040410103203.04ae46b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 10 Apr 2004 10:38:45 -0700 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:58 AM 4/10/2004, Sam Hartman wrote: > Hallvard> See above. Also, Sam's statement that all ANONYMOUS > Hallvard> users have the _same_ authorization ID, not _no_ > Hallvard> authorization ID. Which made me realize that anonymous > Hallvard> auth is not a SASL term, but one I'm used to from LDAP, > Hallvard> where it means the same as no auth. OTOH, FTP (at least > Hallvard> on Unix) implements anonymous auth the way Sam > Hallvard> describes: A specific user on the server's system, with > Hallvard> limited access. > >I think my statement is still generally true. It may happen that the >authorization ID of anonymous users is also the same as the >authorization ID of users who have engaged in no authentication >exchange. But here you are talking about some authorization ID which the service merely associates with the state of being anonymous (having an unknown or concealed identity). This is quite different than saying that anonymous users have established (authenticated) THEIR identity in the service. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AHXcoB060233; Sat, 10 Apr 2004 10:33:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AHXc39060232; Sat, 10 Apr 2004 10:33:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AHXb2m060214 for ; Sat, 10 Apr 2004 10:33:38 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.20) id 1BCMMK-0005x6-Q8; Sat, 10 Apr 2004 19:33:36 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.30) id 1BCMMG-0002ec-6k; Sat, 10 Apr 2004 19:33:32 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BCMMF-0002pc-00; Sat, 10 Apr 2004 19:33:31 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Sam Hartman , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication In-Reply-To: <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sat, 10 Apr 2004 19:33:31 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >At 07:53 AM 4/10/2004, Hallvard B Furuseth wrote: >>Kurt D. Zeilenga writes: >>>At 09:41 AM 4/7/2004, Sam Hartman wrote: >>>>>>>>> "Hallvard" == Hallvard B Furuseth writes: >>>> >>> The anonymous mechanism doesn't provide any >>> authentication service. (Not all SASL mechanisms provide >>> authentication services.) >> >> That's not what rfc2222bis says. It describes SASL mechanisms as >> authentication mechanisms, and describes everything about these in >> terms of authentication. > > Which is a problem. rfc2222bis should be likely use more > generic terms, like "SASL mechanism" when referring to a > SASL mechanism. rfc2222 does the same thing. Did it incorrectly describe existing implementations, or were mechanisms like ANONYMOUS added later? >> One which doesn't authenticate, from what you say. > > I would hope it obvious that ANONYMOUS does not authenticate anything. If it affects the authorization or authentication IDs, it... well, un-authenticates, I suppose. If it doesn't, it seems to violate rfc2222 and rfc2222bis. >> However, I think the ANONYMOUS draft does need to say explicitly how it >> affects the authentication and authorization IDs. > > How any mechanism affects authentication and authorization IDs > outside of the mechanism is beyond the scope of that mechanism. Beyond the scope of any mechanism, I think. Correction: It needs to say which authentication and authorization IDs it _requests_. Or provides, or whatever is the correct term. Hopefully these IDs will be treated just like IDs from other SASL mechanisms. Or like no ID (unauthenticated), if that's what the mechanism requests. > It should be obvious that this mechanism does not itself > establish an authentication identity nor transfer an authorization > identity. However, if more clarity is needed, I would suggest > replacing the paragraph: > This mechanism does not provide a security layer. > with: > This mechanism does not establish the identity of the > client (or user) nor the server (or service); does not > support transfer of an authorization identity; nor > provide a security layer. I think either 'It requests anonymous authentication and authorization identities. How to treat the anonymous ID is up to the protocol or implementation.', or 'It does not affect the authentication and authorization identities'. >> Also, I now wonder how clients typically implement ANONYMOUS. If they >> support several SASL mechanisms, do clients expect the identity to send >> with ANONYMOUS in the same command line option or whatever which they >> use for the authentication IDs for other SASL mechanisms, or do they use >> some other field? > > I suggest you look at some existing implementations. I don't know where to find any... > But > I would hope the user would not be asked or expected to > provide their credentials (or portions of their credentials) > when using this mechanism. If you mean e.g. a password, I agree. However, I was thinking of clients that authenticate to the server and then grant access to something on the client side depending on whether or not authentication succeeds. Such a client must not treat the ID sent with ANONYMOUS as an authentication ID. Or it could refuse the user to specify the ANONYMOUS mechanism, of course. >>> I also find it odd the implication (in Hallvard's comments) that an >>> anonymous user has an established identity. I take the view that an >>> anonymous user is one whose's identity has not been established >> >> See above. Also, Sam's statement that all ANONYMOUS users have the >> _same_ authorization ID, not _no_ authorization ID. > > I think Sam's statement is problematic in that implies that the > mechanism is establishing or authenticating the user's identity. > The server might be associating an identity with anonymous > users, but the server certainly is not establishing > or authenticating the user's identity. I don't see why not. The user just doesn't have anything to do with any information sent in the authentication requests. Instead the user is built into the mechanism itself. Once it is established, it has the access which the server grants that user, just like with authenticated users. >> Which made me realize that anonymous auth is not a SASL term, but one >> I'm used to from LDAP, where it means the same as no auth. OTOH, FTP >> (at least on Unix) implements anonymous auth the way Sam describes: A >> specific user on the server's system, with limited access. > > But it should be clear that anonymous methods in LDAP, FTP, > and elsewhere are not authenticating the user's identity. In LDAP it does not authenticate. In FTP it does, to the server. The anonymous user has the access which the filesystem grants to a specific user on the filesystem. >>> (or is concealed). >> >> Oh dear. I wish you hadn't added that. > > RFC 2828: > $ anonymous > (I) The condition of having a name that is unknown or concealed. > >> Which identity do you mean? > > The identity of the user (or a user). > >> Authentication or authorization identity, after all? > > Both, as they both refer to identities of users. > >> And who is it concealed from? The server, or other users? > > In this case, they are concealed from (at least) the server. Uh... An authorization identity concealed to the server is not a concept I can quite wrap my head around. The server grants access based on some specific authorization identity. >>> Hallvard: I'm not sure what your question is (in your last >>> response). If your asking whether SASL itself or the >>> ANONYMOUS mechanism defines a particular identity representation >>> to refer to anonymous users (users which have no established >>> identity), I think the answer is no. If your asking whether >>> SASL or ANONYMOUS explicitly provides a facility for a user >>> to authenticate oneself and assume the authorization of an >>> anonymous user, I think the answer is no. >> >> Almost... I'm wondering if SASL even allows an authentication >> mechanism to revert the authentication and authorization IDs back >> to unauthenticated - that is, the same state as before the first >> authentication. > > SASL doesn't support "revert", it supports moving to a new > authorization state. Replace "revert" back to "unauthenticated", then. > That new authorization state could be an anonymous one (one where the > identity of the user is not established (authenticated)). I can't find any place in rfc2222bis which says so. Where? >> But perhaps it would be problematic if the did, >> since it would mess up for protocols that require authentication. > > ANONYMOUS allows protocols which previously required authentication > of the user to support processing without authentication of the > user. That is, it allows the "authenticate" command to be used > in a fashion which doesn't actually authenticate anything. -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AGxxZu056401; Sat, 10 Apr 2004 09:59:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AGxx2o056400; Sat, 10 Apr 2004 09:59:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-FIFTY-THREE.MIT.EDU [18.187.6.98]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AGxwph056394 for ; Sat, 10 Apr 2004 09:59:59 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id E78EB15159C; Sat, 10 Apr 2004 13:00:01 -0400 (EDT) To: "Kurt D. Zeilenga" Cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> From: Sam Hartman Date: Sat, 10 Apr 2004 13:00:01 -0400 In-Reply-To: <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> (Kurt D. Zeilenga's message of "Sat, 10 Apr 2004 09:12:40 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> Which is a problem. rfc2222bis should be likely use more Kurt> generic terms, like "SASL mechanism" when referring to a Kurt> SASL mechanism. I don't tend to agree with this. IT seems that viewing anonymous authentication as authentication is a smaller change at this date than assuming not all SASL mechanisms authenticate. >From a practical standpoint, I believe they are isomorphic models. Should I would prefer to choose the model that is most consistent with our documents. --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AGvxGS056182; Sat, 10 Apr 2004 09:57:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AGvxL4056181; Sat, 10 Apr 2004 09:57:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-THREE-FIFTY-THREE.MIT.EDU [18.187.6.98]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AGvxp1056174 for ; Sat, 10 Apr 2004 09:57:59 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 90F0415159C; Sat, 10 Apr 2004 12:58:01 -0400 (EDT) To: Hallvard B Furuseth Cc: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> From: Sam Hartman Date: Sat, 10 Apr 2004 12:58:01 -0400 In-Reply-To: (Hallvard B. Furuseth's message of "Sat, 10 Apr 2004 16:53:53 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard> See above. Also, Sam's statement that all ANONYMOUS Hallvard> users have the _same_ authorization ID, not _no_ Hallvard> authorization ID. Which made me realize that anonymous Hallvard> auth is not a SASL term, but one I'm used to from LDAP, Hallvard> where it means the same as no auth. OTOH, FTP (at least Hallvard> on Unix) implements anonymous auth the way Sam Hallvard> describes: A specific user on the server's system, with Hallvard> limited access. I think my statement is still generally true. It may happen that the authorization ID of anonymous users is also the same as the authorization ID of users who have engaged in no authentication exchange. It may be the case (and generally is) that the authorization ID of anonymous users cannot be represented as a string transmitted over the wire. --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AGDuLo050600; Sat, 10 Apr 2004 09:13:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AGDuRv050599; Sat, 10 Apr 2004 09:13:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AGDteF050593 for ; Sat, 10 Apr 2004 09:13:55 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3AGDwMs032505; Sat, 10 Apr 2004 16:13:58 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040410080958.04a63db8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 10 Apr 2004 09:12:40 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication Cc: Sam Hartman , ietf-sasl@imc.org In-Reply-To: References: <6.0.1.1.0.20040409163319.049d4a38@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 07:53 AM 4/10/2004, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>At 09:41 AM 4/7/2004, Sam Hartman wrote: >> >>>>>>>> "Hallvard" == Hallvard B Furuseth writes: >>> >>> Hallvard> Uh... OTOH, on second reading of rfc2222bis, I can't see >>> Hallvard> that a mechanism may make either ID anonymous at all. >>> Hallvard> It was just so "obvious" that it could do so, that I >>> Hallvard> didn't notice that it couldn't. Anyway, is that >>> Hallvard> intended? >>> >>>I believe the authorization ID of all users authenticated using the >>>anonymous mechanism is the same. >> >> "users authenticated using the anonymous mechanism", I think, >> is a odd phrase. The anonymous mechanism doesn't provide any >> authentication service. (Not all SASL mechanisms provide >> authentication services.) > >That's not what rfc2222bis says. It describes SASL mechanisms as >authentication mechanisms, and describes everything about these in terms >of authentication. Which is a problem. rfc2222bis should be likely use more generic terms, like "SASL mechanism" when referring to a SASL mechanism. >So according to rfc2222bis, ANONYMOUS is an authentication mechanism. rfc2222bis shouldn't imply that all SASL mechanisms provide authentication services. >One which doesn't authenticate, from what you say. I would hope it obvious that ANONYMOUS does not authenticate anything. >Anyway, at first I thought this meant the identity sent with ANONYMOUS >had to be the authentication ID, but I now notice that this is wrong. The only information ANONYMOUS transfers is for trace purposes. It has no semantical value to the mechanism. >However, I think the ANONYMOUS draft does need to say explicitly how it >affects the authentication and authorization IDs. How any mechanism affects authentication and authorization IDs outside of the mechanism is beyond the scope of that mechanism. It should be obvious that this mechanism does not itself establish an authentication identity nor transfer an authorization identity. However, if more clarity is needed, I would suggest replacing the paragraph: This mechanism does not provide a security layer. with: This mechanism does not establish the identity of the client (or user) nor the server (or service); does not support transfer of an authorization identity; nor provide a security layer. and relocate this paragraph more towards the top of the section. >Also, I now wonder how clients typically implement ANONYMOUS. If they >support several SASL mechanisms, do clients expect the identity to send >with ANONYMOUS in the same command line option or whatever which they >use for the authentication IDs for other SASL mechanisms, or do they use >some other field? I suggest you look at some existing implementations. But I would hope the user would not be asked or expected to provide their credentials (or portions of their credentials) when using this mechanism. >Anyway, > >> I also find it odd the implication (in Hallvard's comments) that an >> anonymous user has an established identity. I take the view that an >> anonymous user is one whose's identity has not been established > >See above. Also, Sam's statement that all ANONYMOUS users have the >_same_ authorization ID, not _no_ authorization ID. I think Sam's statement is problematic in that implies that the mechanism is establishing or authenticating the user's identity. The server might be associating an identity with anonymous users, but the server certainly is not establishing or authenticating the user's identity. >Which made me realize that anonymous auth is not a SASL term, but one I'm used to from >LDAP, where it means the same as no auth. OTOH, FTP (at least on Unix) >implements anonymous auth the way Sam describes: A specific user on the >server's system, with limited access. But it should be clear that anonymous methods in LDAP, FTP, and elsewhere are not authenticating the user's identity. >> (or is concealed). > >Oh dear. I wish you hadn't added that. RFC 2828: $ anonymous (I) The condition of having a name that is unknown or concealed. >Which identity do you mean? The identity of the user (or a user). >Authentication or authorization identity, after all? Both, as they both refer to identities of users. >And who is it concealed from? The server, or other users? In this case, they are concealed from (at least) the server. >> Hallvard: I'm not sure what your question is (in your last >> response). If your asking whether SASL itself or the >> ANONYMOUS mechanism defines a particular identity representation >> to refer to anonymous users (users which have no established >> identity), I think the answer is no. If your asking whether >> SASL or ANONYMOUS explicitly provides a facility for a user >> to authenticate oneself and assume the authorization of an >> anonymous user, I think the answer is no. > >Almost... I'm wondering if SASL even allows an authentication >mechanism to revert the authentication and authorization IDs back >to unauthenticated - that is, the same state as before the first >authentication. SASL doesn't support "revert", it supports moving to a new authorization state. That new authorization state could be an anonymous one (one where the identity of the user is not established (authenticated)). >But perhaps it would be problematic if the did, >since it would mess up for protocols that require authentication. ANONYMOUS allows protocols which previously required authentication of the user to support processing without authentication of the user. That is, it allows the "authenticate" command to be used in a fashion which doesn't actually authenticate anything. Which, BTW, >(BTW, note the command 'A002 AUTHENTICATE ANONYMOUS' in the >example in the ANONYMOUS draft.) is what's happening here. This AUTHENTICATE command does not cause anything to be authenticated. >Maybe an 'anonymous user' is a better concept, which protocols >can treat either the same way as unauthenticated or as a normal >user with limited access. > >> I note, nothing explicitly prevents application protocol >> specifications from providing such facilities, including >> by means of defining a particular identity representation >> to refer to users who have not established their identity. > >-- >Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AEs4vF039535; Sat, 10 Apr 2004 07:54:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3AEs4mw039534; Sat, 10 Apr 2004 07:54:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AEs3GN039517 for ; Sat, 10 Apr 2004 07:54:03 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1BCJrq-0001j9-39; Sat, 10 Apr 2004 16:53:58 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.30) id 1BCJrm-0005NS-PM; Sat, 10 Apr 2004 16:53:54 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BCJrl-0002SW-00; Sat, 10 Apr 2004 16:53:53 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: Sam Hartman , ietf-sasl@imc.org Subject: Re: Half-anonymous authentication In-Reply-To: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> References: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sat, 10 Apr 2004 16:53:53 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt D. Zeilenga writes: >At 09:41 AM 4/7/2004, Sam Hartman wrote: > >>>>>>> "Hallvard" == Hallvard B Furuseth writes: >> >> Hallvard> Uh... OTOH, on second reading of rfc2222bis, I can't see >> Hallvard> that a mechanism may make either ID anonymous at all. >> Hallvard> It was just so "obvious" that it could do so, that I >> Hallvard> didn't notice that it couldn't. Anyway, is that >> Hallvard> intended? >> >>I believe the authorization ID of all users authenticated using the >>anonymous mechanism is the same. > > "users authenticated using the anonymous mechanism", I think, > is a odd phrase. The anonymous mechanism doesn't provide any > authentication service. (Not all SASL mechanisms provide > authentication services.) That's not what rfc2222bis says. It describes SASL mechanisms as authentication mechanisms, and describes everything about these in terms of authentication. So according to rfc2222bis, ANONYMOUS is an authentication mechanism. One which doesn't authenticate, from what you say. (BTW, note the command 'A002 AUTHENTICATE ANONYMOUS' in the example in the ANONYMOUS draft.) Anyway, at first I thought this meant the identity sent with ANONYMOUS had to be the authentication ID, but I now notice that this is wrong. However, I think the ANONYMOUS draft does need to say explicitly how it affects the authentication and authorization IDs. Also, I now wonder how clients typically implement ANONYMOUS. If they support several SASL mechanisms, do clients expect the identity to send with ANONYMOUS in the same command line option or whatever which they use for the authentication IDs for other SASL mechanisms, or do they use some other field? Anyway, > I also find it odd the implication (in Hallvard's comments) that an > anonymous user has an established identity. I take the view that an > anonymous user is one whose's identity has not been established See above. Also, Sam's statement that all ANONYMOUS users have the _same_ authorization ID, not _no_ authorization ID. Which made me realize that anonymous auth is not a SASL term, but one I'm used to from LDAP, where it means the same as no auth. OTOH, FTP (at least on Unix) implements anonymous auth the way Sam describes: A specific user on the server's system, with limited access. > (or is concealed). Oh dear. I wish you hadn't added that. Which identity do you mean? Authentication or authorization identity, after all? And who is it concealed from? The server, or other users? > Hallvard: I'm not sure what your question is (in your last > response). If your asking whether SASL itself or the > ANONYMOUS mechanism defines a particular identity representation > to refer to anonymous users (users which have no established > identity), I think the answer is no. If your asking whether > SASL or ANONYMOUS explicitly provides a facility for a user > to authenticate oneself and assume the authorization of an > anonymous user, I think the answer is no. Almost... I'm wondering if SASL even allows an authentication mechanism to revert the authentication and authorization IDs back to unauthenticated - that is, the same state as before the first authentication. But perhaps it would be problematic if the did, since it would mess up for protocols that require authentication. Maybe an 'anonymous user' is a better concept, which protocols can treat either the same way as unauthenticated or as a normal user with limited access. > I note, nothing explicitly prevents application protocol > specifications from providing such facilities, including > by means of defining a particular identity representation > to refer to users who have not established their identity. -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3A06RtD066022; Fri, 9 Apr 2004 17:06:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3A06RCQ066021; Fri, 9 Apr 2004 17:06:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3A06QFN066015 for ; Fri, 9 Apr 2004 17:06:26 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3A06VMs017628; Sat, 10 Apr 2004 00:06:32 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040409163319.049d4a38@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 09 Apr 2004 17:06:16 -0700 To: Sam Hartman , Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Half-anonymous authentication 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 09:41 AM 4/7/2004, Sam Hartman wrote: >>>>>> "Hallvard" == Hallvard B Furuseth writes: > > Hallvard> Uh... OTOH, on second reading of rfc2222bis, I can't see > Hallvard> that a mechanism may make either ID anonymous at all. > Hallvard> It was just so "obvious" that it could do so, that I > Hallvard> didn't notice that it couldn't. Anyway, is that > Hallvard> intended? > >I believe the authorization ID of all users authenticated using the >anonymous mechanism is the same. "users authenticated using the anonymous mechanism", I think, is a odd phrase. The anonymous mechanism doesn't provide any authentication service. (Not all SASL mechanisms provide authentication services.) I also find it odd the implication (in Hallvard's comments) that an anonymous user has an established identity. I take the view that an anonymous user is one whose's identity has not been established (or is concealed). While some implementations (and maybe even some application protocols) might associate a particular identity representation to users who are anonymous (have no established identity), this by no means implies that anonymous mechanism establishes (authenticates) the identity of the user. It doesn't. Hallvard: I'm not sure what your question is (in your last response). If your asking whether SASL itself or the ANONYMOUS mechanism defines a particular identity representation to refer to anonymous users (users which have no established identity), I think the answer is no. If your asking whether SASL or ANONYMOUS explicitly provides a facility for a user to authenticate oneself and assume the authorization of an anonymous user, I think the answer is no. I note, nothing explicitly prevents application protocol specifications from providing such facilities, including by means of defining a particular identity representation to refer to users who have not established their identity. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39KruoU044565; Fri, 9 Apr 2004 13:53:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39Kru6T044564; Fri, 9 Apr 2004 13:53:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39KrtTp044557 for ; Fri, 9 Apr 2004 13:53:55 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i39KrsMs014616; Fri, 9 Apr 2004 20:53:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040409134944.04aa9da0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 09 Apr 2004 13:53:39 -0700 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Family of mechanism (Was: draft-ietf-sasl-crammd5-02 / additional mechanisms ?) Cc: ietf-sasl@imc.org In-Reply-To: References: <20040408102601.GA25498@mcmilk.de> <20040409073807.GA15126@mcmilk.de> 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:54 AM 4/9/2004, Simon Josefsson wrote: >One idea for solving this problem would be to make the SASL mechanism >family matter purely an IETF/IANA procedural matter, and not an >intrinsic part of the SASL protocol. It should be clear in the revised SASL base specification, if not already so, that families of mechanisms is purely a name space matter. To the protocol, each name/mechanism is independent of all other name/mechanism pairs. Kurt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39Kbcmv042828; Fri, 9 Apr 2004 13:37:38 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39Kbccp042827; Fri, 9 Apr 2004 13:37:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39KbXWA042813 for ; Fri, 9 Apr 2004 13:37:34 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BC2ks-0003Pn-00 for ; Fri, 09 Apr 2004 22:37:38 +0200 Received: from h246n3c1o299.bredband.skanova.com ([217.208.174.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Apr 2004 22:37:38 +0200 Received: from jas by h246n3c1o299.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Apr 2004 22:37:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Date: Fri, 09 Apr 2004 22:37:33 +0200 Lines: 49 Message-ID: References: <20040408102601.GA25498@mcmilk.de> <20040409073807.GA15126@mcmilk.de> <20040409174534.GA9707@mcmilk.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h246n3c1o299.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:w3uSLJKW9MRW3uxSLUDknYXVXV4= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tino Reichardt writes: >> But the code that selects the proper module to implement a specific >> SASL mechanism, based on a family name, will be more complicated than >> it was in 2222. To use GSS as an example (since there is a >> specification for it, so we can get into details), to be flexible the >> SASL library would have to recognize the "GSS-" prefix, and load >> e.g. libgsasl-gss.so, which in turn loads the GSS implementation, >> iterates over all supported GSS mechanisms (which can change over >> time, without the SASL library knowing about it), compute the >> truncated MD5 and check whether it match the GSS- string. >> Compare this to the 2222 approach, where you load (e.g.) >> libgsasl-.so and that's it. > > The applications should just load what they need to support some > special typ of SASL mechanism. But such a implementation can't be the > reason for not specifying new mechanisms. Right, the argument was a reason for not introducing SASL mechanism families at all, at least not as a protocol matter, in 2222bis. Don't take it as criticism of your idea specifically, it wasn't meant as such. Your idea just made me think of the general topic of SASL mechanism families. >> Yes. Or, if 2222bis is approved with SASL mechanism families, you can >> write a document for the entire CRAM-* family, if you make sure it >> doesn't collide with CRAM-MD5. > > HMAC-SHA1 and HMAC-RIPEMD is also spcified in rfc 2104. So why > shouldn't CRAM-SHA1 + CRAM-RIPEMD be mentioned in a new CRAM-MD5 rfc ? > Maybe the name isn't the best one than - okay :) As Kurt Zeilenga said, the agenda for CRAM-MD5 is rather limited. Delaying it further because it can be generalized, does not sound like a good idea to me. This doesn't mean you can't work on CRAM-* in parallel though, and since you quoted existing software that uses it, having it documented and registered with IANA would be a good idea. The document for CRAM-* could begin by explaining what the technical motivations for developing it was. At least I'm curious about that. (Don't you trust MD5? Is the code size of MD5 too large? Etc.) >> It appears as if a document describing CRAM-SHA1 would be a useful >> contribution. You can add a link to it on the IANA SASL page. > Who? See http://www.iana.org/assignments/sasl-mechanisms Regards, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39KTqXi042019; Fri, 9 Apr 2004 13:29:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39KTq0f042018; Fri, 9 Apr 2004 13:29:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.svc-box.de ([66.111.56.110]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39KToYJ042010 for ; Fri, 9 Apr 2004 13:29:51 -0700 (PDT) (envelope-from list-ietf-sasl@mcmilk.de) Received: (qmail 32135 invoked by uid 101); 9 Apr 2004 20:29:54 -0000 Date: Fri, 9 Apr 2004 22:29:54 +0200 From: Tino Reichardt To: ietf-sasl@imc.org Subject: Re: [corrected] Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Message-ID: <20040409202954.GA30779@mcmilk.de> Reply-To: Tino Reichardt Mail-Followup-To: Tino Reichardt , ietf-sasl@imc.org References: <6.0.1.1.0.20040409124008.04a88ab0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.1.1.0.20040409124008.04a88ab0@127.0.0.1> User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * "Kurt D. Zeilenga" wrote: > > My previous note had a few unfortunate typos in it. This should be > more clear. Sorry for any confusion. -- Kurt No problem :) > Tino, > > The SASL WG's CRAM-MD5 work item is limited to revising the SASL > CRAM-MD5 authentication mechanism. Engineering of other CRAM-based > mechanisms is simply beyond the scope of this working group. I > suggest you pursue the specification of other mechanisms on an > individual basis. Okay, I will do so. > > I do note that this list is an acceptable forum for review of > SASL-related submissions produced by individuals (as long as > such review does not impede progress on WG deliverables). Sorry, if I was to pertly :) -- regards, TR Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39Jfr6j036742; Fri, 9 Apr 2004 12:41:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39JfrPb036741; Fri, 9 Apr 2004 12:41:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39JfqjA036735 for ; Fri, 9 Apr 2004 12:41:52 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i39JfvMs013115; Fri, 9 Apr 2004 19:41:57 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040409124008.04a88ab0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 09 Apr 2004 12:41:41 -0700 To: Tino Reichardt From: "Kurt D. Zeilenga" Subject: [corrected] Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Cc: ietf-sasl@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: My previous note had a few unfortunate typos in it. This should be more clear. Sorry for any confusion. -- Kurt Tino, The SASL WG's CRAM-MD5 work item is limited to revising the SASL CRAM-MD5 authentication mechanism. Engineering of other CRAM-based mechanisms is simply beyond the scope of this working group. I suggest you pursue the specification of other mechanisms on an individual basis. I do note that this list is an acceptable forum for review of SASL-related submissions produced by individuals (as long as such review does not impede progress on WG deliverables). Regards, Kurt (as co-chair of the SASL-WG) At 03:26 AM 4/8/2004, Tino Reichardt wrote: >Hello ietf-sasl list. > >First of all: my english isn't the best and I am new to this list. > >I think the draft 'The CRAM-MD5 SASL Mechanism' should not only >specify the CRAM-MD5 mechanism. >Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar >and then specify also some other standard hash routines as SASL CRAM >mechanisms: > >: CRAM-MD5 >160bit: CRAM-SHA1 >160bit: CRAM-RIPEMD-160 >320bit: CRAM-RIPEMD-320 > > >ps: The CRAM-SHA1 mechanism is already used by serveral servers and > clients. > > >references: > >[SHA1] http://www.itl.nist.gov/fipspubs/fip180-1.htm >[RIPEMD] http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html > > >-- >regards, TR Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39Ig4OG029316; Fri, 9 Apr 2004 11:42:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39Ig4qA029315; Fri, 9 Apr 2004 11:42:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39Ig3ZN029309 for ; Fri, 9 Apr 2004 11:42:03 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i39Ig7Ms012047; Fri, 9 Apr 2004 18:42:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040409112800.04a86188@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 09 Apr 2004 11:41:52 -0700 To: Tino Reichardt From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Cc: ietf-sasl@imc.org In-Reply-To: <20040408102601.GA25498@mcmilk.de> References: <20040408102601.GA25498@mcmilk.de> 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: Tino, The WG CRAM-MD5 work item is limited to revising the SASL CRAM-MD5 authentication mechanism. Engineering of other CRAM-based mechanisms is simply beyond the scope of the working group. I suggest you pursue the specification of other mechanisms on an individual basis. I do not that this list is an acceptable forum for review of SASL-related submissions produced by individuals (as long as such review does not impede progress on WG deliverables). Regards, Kurt (as co-chair of the SASL-WG) At 03:26 AM 4/8/2004, Tino Reichardt wrote: >Hello ietf-sasl list. > >First of all: my english isn't the best and I am new to this list. > >I think the draft 'The CRAM-MD5 SASL Mechanism' should not only >specify the CRAM-MD5 mechanism. >Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar >and then specify also some other standard hash routines as SASL CRAM >mechanisms: > >: CRAM-MD5 >160bit: CRAM-SHA1 >160bit: CRAM-RIPEMD-160 >320bit: CRAM-RIPEMD-320 > > >ps: The CRAM-SHA1 mechanism is already used by serveral servers and > clients. > > >references: > >[SHA1] http://www.itl.nist.gov/fipspubs/fip180-1.htm >[RIPEMD] http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html > > >-- >regards, TR Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39HjXZ0023685; Fri, 9 Apr 2004 10:45:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39HjXlg023684; Fri, 9 Apr 2004 10:45:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.svc-box.de ([66.111.56.110]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39HjVnr023678 for ; Fri, 9 Apr 2004 10:45:32 -0700 (PDT) (envelope-from list-ietf-sasl@mcmilk.de) Received: (qmail 16831 invoked by uid 101); 9 Apr 2004 17:45:34 -0000 Date: Fri, 9 Apr 2004 19:45:34 +0200 From: Tino Reichardt To: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Message-ID: <20040409174534.GA9707@mcmilk.de> Reply-To: Tino Reichardt Mail-Followup-To: Tino Reichardt , ietf-sasl@imc.org References: <20040408102601.GA25498@mcmilk.de> <20040409073807.GA15126@mcmilk.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * Simon Josefsson wrote: > > Tino Reichardt writes: > > > * Simon Josefsson wrote: > >> > >> Tino Reichardt writes: > >> > >> > I think the draft 'The CRAM-MD5 SASL Mechanism' should not only > >> > specify the CRAM-MD5 mechanism. > >> > Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar > >> > and then specify also some other standard hash routines as SASL CRAM > >> > mechanisms: > >> > > >> > : CRAM-MD5 > >> > 160bit: CRAM-SHA1 > >> > 160bit: CRAM-RIPEMD-160 > >> > 320bit: CRAM-RIPEMD-320 > >> > >> For what it's worth, I'm not convinced this is a good idea. Unless > >> there is something wrong with the authentication part of CRAM-MD5, it > >> would only decrease interoperability if variations were added. > >> Especially considering that a stored, non-plain, password database is > >> not compatible across hash functions. > > This is true ... can you tell me applications where contexts are > > stored ? > > I believe Cyrus SASL has a mode in which it doesn't store plain-text > passwords, only mechanism specific contexts. I'm sure other > implementations can do the same. Okay, but for SMTP + POP3 servers doesn't that matter, because the initial server response differs every time ... So storing contexts here, makes no sense. As far as I know - Maybe I am on the wrong track :) > > >> Further, I dislike SASL mechanism families. This also applies to the > >> new GSS-API mechanisms. It is a change compared to 2222, and it makes > >> the generic parts of a SASL library needlessly complicated (think > >> dynamically loading the proper SASL module based on SASL mechanism > >> name). > > Do you think on a special application ? Who loads what dynamically ? > > Adding SHA1 + RIPEMD hash algorithms to an application isn't very > > complex... just see [QPASSWD]. > > This was a generic comment, not specific to CRAM-*. Adding code for > SHA1/RIPEMD is easy, I agree. > > But the code that selects the proper module to implement a specific > SASL mechanism, based on a family name, will be more complicated than > it was in 2222. To use GSS as an example (since there is a > specification for it, so we can get into details), to be flexible the > SASL library would have to recognize the "GSS-" prefix, and load > e.g. libgsasl-gss.so, which in turn loads the GSS implementation, > iterates over all supported GSS mechanisms (which can change over > time, without the SASL library knowing about it), compute the > truncated MD5 and check whether it match the GSS- string. > Compare this to the 2222 approach, where you load (e.g.) > libgsasl-.so and that's it. The applications should just load what they need to support some special typ of SASL mechanism. But such a implementation can't be the reason for not specifying new mechanisms. They have to load for every new SASL mechanism another library, when it doesn't work another way. Maybe the concept of those implementations is wrong, because when I want to by a car, I don't choose the tires first and then the car, which has to fit to them. > > One idea for solving this problem would be to make the SASL mechanism > family matter purely an IETF/IANA procedural matter, and not an > intrinsic part of the SASL protocol. I mean, the GSS SASL mechanism > should not imply that an implementation should go through the above > procedure in order to find the proper GSS mechanism to use, but that > each GSS mechanism to be used within SASL is registered as such, using > the truncated MD5 as the registered name, and only after that should > SASL implementations be assumed to recognize it automatically. (Of > course, we can't stop implementations from recognizing non-standard > SASL mechanisms, perhaps by implementing the above algorithm.) Hm... > >> Still, nothing prevents you from register CRAM-SHA1 at IANA, write > >> your own specification, and using it. But, to re-iterate, I believe > >> it isn't useful to change the current CRAM-MD5 document into a CRAM-* > >> family. If you need a SASL mechanism that can use other hashes, have > >> a look at GSS-*, or perhaps KERBEROS_V5. > > Okay, we need for every good hash a good draft ? > > Yes. Or, if 2222bis is approved with SASL mechanism families, you can > write a document for the entire CRAM-* family, if you make sure it > doesn't collide with CRAM-MD5. HMAC-SHA1 and HMAC-RIPEMD is also spcified in rfc 2104. So why shouldn't CRAM-SHA1 + CRAM-RIPEMD be mentioned in a new CRAM-MD5 rfc ? Maybe the name isn't the best one than - okay :) > It appears as if a document describing CRAM-SHA1 would be a useful > contribution. You can add a link to it on the IANA SASL page. Who? -- regards, TR Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39AsDgI071006; Fri, 9 Apr 2004 03:54:13 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39AsDMO071005; Fri, 9 Apr 2004 03:54:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39As9Fr070998 for ; Fri, 9 Apr 2004 03:54:09 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BBteD-00008m-00 for ; Fri, 09 Apr 2004 12:54:09 +0200 Received: from h246n3c1o299.bredband.skanova.com ([217.208.174.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Apr 2004 12:54:09 +0200 Received: from jas by h246n3c1o299.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Apr 2004 12:54:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Date: Fri, 09 Apr 2004 12:54:05 +0200 Lines: 103 Message-ID: References: <20040408102601.GA25498@mcmilk.de> <20040409073807.GA15126@mcmilk.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h246n3c1o299.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:LICyAxXKMJ2RG80AW0HISuHUHx8= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tino Reichardt writes: > * Simon Josefsson wrote: >> >> Tino Reichardt writes: >> >> > I think the draft 'The CRAM-MD5 SASL Mechanism' should not only >> > specify the CRAM-MD5 mechanism. >> > Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar >> > and then specify also some other standard hash routines as SASL CRAM >> > mechanisms: >> > >> > : CRAM-MD5 >> > 160bit: CRAM-SHA1 >> > 160bit: CRAM-RIPEMD-160 >> > 320bit: CRAM-RIPEMD-320 >> >> For what it's worth, I'm not convinced this is a good idea. Unless >> there is something wrong with the authentication part of CRAM-MD5, it >> would only decrease interoperability if variations were added. >> Especially considering that a stored, non-plain, password database is >> not compatible across hash functions. > This is true ... can you tell me applications where contexts are > stored ? I believe Cyrus SASL has a mode in which it doesn't store plain-text passwords, only mechanism specific contexts. I'm sure other implementations can do the same. >> Further, I dislike SASL mechanism families. This also applies to the >> new GSS-API mechanisms. It is a change compared to 2222, and it makes >> the generic parts of a SASL library needlessly complicated (think >> dynamically loading the proper SASL module based on SASL mechanism >> name). > Do you think on a special application ? Who loads what dynamically ? > Adding SHA1 + RIPEMD hash algorithms to an application isn't very > complex... just see [QPASSWD]. This was a generic comment, not specific to CRAM-*. Adding code for SHA1/RIPEMD is easy, I agree. But the code that selects the proper module to implement a specific SASL mechanism, based on a family name, will be more complicated than it was in 2222. To use GSS as an example (since there is a specification for it, so we can get into details), to be flexible the SASL library would have to recognize the "GSS-" prefix, and load e.g. libgsasl-gss.so, which in turn loads the GSS implementation, iterates over all supported GSS mechanisms (which can change over time, without the SASL library knowing about it), compute the truncated MD5 and check whether it match the GSS- string. Compare this to the 2222 approach, where you load (e.g.) libgsasl-.so and that's it. One idea for solving this problem would be to make the SASL mechanism family matter purely an IETF/IANA procedural matter, and not an intrinsic part of the SASL protocol. I mean, the GSS SASL mechanism should not imply that an implementation should go through the above procedure in order to find the proper GSS mechanism to use, but that each GSS mechanism to be used within SASL is registered as such, using the truncated MD5 as the registered name, and only after that should SASL implementations be assumed to recognize it automatically. (Of course, we can't stop implementations from recognizing non-standard SASL mechanisms, perhaps by implementing the above algorithm.) >> Still, nothing prevents you from register CRAM-SHA1 at IANA, write >> your own specification, and using it. But, to re-iterate, I believe >> it isn't useful to change the current CRAM-MD5 document into a CRAM-* >> family. If you need a SASL mechanism that can use other hashes, have >> a look at GSS-*, or perhaps KERBEROS_V5. > Okay, we need for every good hash a good draft ? Yes. Or, if 2222bis is approved with SASL mechanism families, you can write a document for the entire CRAM-* family, if you make sure it doesn't collide with CRAM-MD5. >> > ps: The CRAM-SHA1 mechanism is already used by serveral servers and >> > clients. >> >> Do you have any pointers? > Not much, but since it isn't mentioned in any standard: > > Hamster SMTP+POP3+NNTP Server/Client: > http://www.tglsoft.de/misc/hamster_en.htm > > Cone Mail Client: > http://www.courier-mta.org/cone/cone00index.html > > Radius Server: > http://www.freeradius.org > (http://www.freeradius.org/radiusd/doc/ChangeLog) > > also: > - courier-imapd > - postfix > > > [QPASSWD] http://www.mcmilk.de/projects/qpasswd/ It appears as if a document describing CRAM-SHA1 would be a useful contribution. You can add a link to it on the IANA SASL page. Regards, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i397cQGo017086; Fri, 9 Apr 2004 00:38:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i397cQqF017085; Fri, 9 Apr 2004 00:38:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.svc-box.de ([66.111.56.110]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i397c9Vw016974 for ; Fri, 9 Apr 2004 00:38:26 -0700 (PDT) (envelope-from list-ietf-sasl@mcmilk.de) Received: (qmail 21018 invoked by uid 101); 9 Apr 2004 07:38:08 -0000 Date: Fri, 9 Apr 2004 09:38:08 +0200 From: Tino Reichardt To: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Message-ID: <20040409073807.GA15126@mcmilk.de> Reply-To: Tino Reichardt Mail-Followup-To: Tino Reichardt , ietf-sasl@imc.org References: <20040408102601.GA25498@mcmilk.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * Simon Josefsson wrote: > > Tino Reichardt writes: > > > I think the draft 'The CRAM-MD5 SASL Mechanism' should not only > > specify the CRAM-MD5 mechanism. > > Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar > > and then specify also some other standard hash routines as SASL CRAM > > mechanisms: > > > > : CRAM-MD5 > > 160bit: CRAM-SHA1 > > 160bit: CRAM-RIPEMD-160 > > 320bit: CRAM-RIPEMD-320 > > For what it's worth, I'm not convinced this is a good idea. Unless > there is something wrong with the authentication part of CRAM-MD5, it > would only decrease interoperability if variations were added. > Especially considering that a stored, non-plain, password database is > not compatible across hash functions. This is true ... can you tell me applications where contexts are stored ? > > Further, I dislike SASL mechanism families. This also applies to the > new GSS-API mechanisms. It is a change compared to 2222, and it makes > the generic parts of a SASL library needlessly complicated (think > dynamically loading the proper SASL module based on SASL mechanism > name). Do you think on a special application ? Who loads what dynamically ? Adding SHA1 + RIPEMD hash algorithms to an application isn't very complex... just see [QPASSWD]. > > Still, nothing prevents you from register CRAM-SHA1 at IANA, write > your own specification, and using it. But, to re-iterate, I believe > it isn't useful to change the current CRAM-MD5 document into a CRAM-* > family. If you need a SASL mechanism that can use other hashes, have > a look at GSS-*, or perhaps KERBEROS_V5. Okay, we need for every good hash a good draft ? > > > ps: The CRAM-SHA1 mechanism is already used by serveral servers and > > clients. > > Do you have any pointers? Not much, but since it isn't mentioned in any standard: Hamster SMTP+POP3+NNTP Server/Client: http://www.tglsoft.de/misc/hamster_en.htm Cone Mail Client: http://www.courier-mta.org/cone/cone00index.html Radius Server: http://www.freeradius.org (http://www.freeradius.org/radiusd/doc/ChangeLog) also: - courier-imapd - postfix [QPASSWD] http://www.mcmilk.de/projects/qpasswd/ -- regards, TR Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38LMaLn011483; Thu, 8 Apr 2004 14:22:36 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38LMaEv011482; Thu, 8 Apr 2004 14:22:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38LMWhD011473 for ; Thu, 8 Apr 2004 14:22:33 -0700 (PDT) (envelope-from gis-ietf-sasl-560@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BBgym-0002OL-00 for ; Thu, 08 Apr 2004 23:22:32 +0200 Received: from h246n3c1o299.bredband.skanova.com ([217.208.174.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Apr 2004 23:22:32 +0200 Received: from jas by h246n3c1o299.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Apr 2004 23:22:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-sasl@imc.org From: Simon Josefsson Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Date: Thu, 08 Apr 2004 23:22:28 +0200 Lines: 38 Message-ID: References: <20040408102601.GA25498@mcmilk.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h246n3c1o299.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:yPsGiWO39gDyhgw2Q376kQO4L8w= Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tino Reichardt writes: > I think the draft 'The CRAM-MD5 SASL Mechanism' should not only > specify the CRAM-MD5 mechanism. > Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar > and then specify also some other standard hash routines as SASL CRAM > mechanisms: > > : CRAM-MD5 > 160bit: CRAM-SHA1 > 160bit: CRAM-RIPEMD-160 > 320bit: CRAM-RIPEMD-320 For what it's worth, I'm not convinced this is a good idea. Unless there is something wrong with the authentication part of CRAM-MD5, it would only decrease interoperability if variations were added. Especially considering that a stored, non-plain, password database is not compatible across hash functions. Further, I dislike SASL mechanism families. This also applies to the new GSS-API mechanisms. It is a change compared to 2222, and it makes the generic parts of a SASL library needlessly complicated (think dynamically loading the proper SASL module based on SASL mechanism name). Still, nothing prevents you from register CRAM-SHA1 at IANA, write your own specification, and using it. But, to re-iterate, I believe it isn't useful to change the current CRAM-MD5 document into a CRAM-* family. If you need a SASL mechanism that can use other hashes, have a look at GSS-*, or perhaps KERBEROS_V5. > ps: The CRAM-SHA1 mechanism is already used by serveral servers and > clients. Do you have any pointers? Thanks, Simon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38FiQC8091398; Thu, 8 Apr 2004 08:44:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38FiQZv091397; Thu, 8 Apr 2004 08:44:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38FiK4w091378 for ; Thu, 8 Apr 2004 08:44:25 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 8 Apr 2004 16:43:41 +0100 Message-ID: <40757325.80401@isode.com> Date: Thu, 08 Apr 2004 16:43:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tino Reichardt CC: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ? References: <20040408102601.GA25498@mcmilk.de> In-Reply-To: <20040408102601.GA25498@mcmilk.de> 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: Tino Reichardt wrote: >Hello ietf-sasl list. > >First of all: my english isn't the best and I am new to this list. > >I think the draft 'The CRAM-MD5 SASL Mechanism' should not only >specify the CRAM-MD5 mechanism. >Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar >and then specify also some other standard hash routines as SASL CRAM >mechanisms: > >: CRAM-MD5 >160bit: CRAM-SHA1 >160bit: CRAM-RIPEMD-160 >320bit: CRAM-RIPEMD-320 > I am afraid documenting those is outside of the scope for this working group. However you can contact me offline if you want to document this/help out to document this. >ps: The CRAM-SHA1 mechanism is already used by serveral servers and > clients. > > >references: > >[SHA1] http://www.itl.nist.gov/fipspubs/fip180-1.htm >[RIPEMD] http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html > > Regards, Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38AQ4b3065140; Thu, 8 Apr 2004 03:26:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38AQ4Sf065139; Thu, 8 Apr 2004 03:26:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail.svc-box.de ([66.111.56.110]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38AQ0Qh065132 for ; Thu, 8 Apr 2004 03:26:03 -0700 (PDT) (envelope-from list-ietf-sasl@mcmilk.de) Received: (qmail 32461 invoked by uid 101); 8 Apr 2004 10:26:01 -0000 Date: Thu, 8 Apr 2004 12:26:01 +0200 From: Tino Reichardt To: ietf-sasl@imc.org Subject: draft-ietf-sasl-crammd5-02 / additional mechanisms ? Message-ID: <20040408102601.GA25498@mcmilk.de> Reply-To: Tino Reichardt Mail-Followup-To: Tino Reichardt , ietf-sasl@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello ietf-sasl list. First of all: my english isn't the best and I am new to this list. I think the draft 'The CRAM-MD5 SASL Mechanism' should not only specify the CRAM-MD5 mechanism. Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar and then specify also some other standard hash routines as SASL CRAM mechanisms: : CRAM-MD5 160bit: CRAM-SHA1 160bit: CRAM-RIPEMD-160 320bit: CRAM-RIPEMD-320 ps: The CRAM-SHA1 mechanism is already used by serveral servers and clients. references: [SHA1] http://www.itl.nist.gov/fipspubs/fip180-1.htm [RIPEMD] http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html -- regards, TR Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37HUh4m014617; Wed, 7 Apr 2004 10:30:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37HUhbE014616; Wed, 7 Apr 2004 10:30:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37HUgDH014601 for ; Wed, 7 Apr 2004 10:30:43 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1BBGst-0006Ei-49; Wed, 07 Apr 2004 19:30:43 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.30) id 1BBGsq-0004Gy-Sh; Wed, 07 Apr 2004 19:30:40 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BBGsq-00009k-00; Wed, 7 Apr 2004 19:30:40 +0200 From: Hallvard B Furuseth Message-Id: To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: Half-anonymous authentication In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 7 Apr 2004 19:30:40 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: > >>>>> "Hallvard" == Hallvard B Furuseth writes: > > Hallvard> Uh... OTOH, on second reading of rfc2222bis, I can't see > Hallvard> that a mechanism may make either ID anonymous at all. > Hallvard> It was just so "obvious" that it could do so, that I > Hallvard> didn't notice that it couldn't. Anyway, is that > Hallvard> intended? > > I believe the authorization ID of all users authenticated using the > anonymous mechanism is the same. Not that I can see. However, Security Considerations refer to 'the anonymous user'. Looks like a good idea for the section which defines the mechanism. However, for SASL in general I was thinking of explicitly setting up the connection to have the same authorization or authentication ID as unauthenticated connections, not setting them to a special 'anonymous user'. The former is called 'anonymous' in LDAP. Sorry about bringing the term over here without explaining. -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37GfAc0010735; Wed, 7 Apr 2004 09:41:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37GfAr6010734; Wed, 7 Apr 2004 09:41:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-TWO-SIXTY-SEVEN.MIT.EDU [18.187.6.12]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37Gf9Su010722 for ; Wed, 7 Apr 2004 09:41:09 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id ACF3D15159C; Wed, 7 Apr 2004 12:41:04 -0400 (EDT) To: Hallvard B Furuseth Cc: ietf-sasl@imc.org Subject: Re: Half-anonymous authentication References: From: Sam Hartman Date: Wed, 07 Apr 2004 12:41:04 -0400 In-Reply-To: (Hallvard B. Furuseth's message of "Tue, 6 Apr 2004 22:25:40 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Hallvard" == Hallvard B Furuseth writes: Hallvard> Uh... OTOH, on second reading of rfc2222bis, I can't see Hallvard> that a mechanism may make either ID anonymous at all. Hallvard> It was just so "obvious" that it could do so, that I Hallvard> didn't notice that it couldn't. Anyway, is that Hallvard> intended? I believe the authorization ID of all users authenticated using the anonymous mechanism is the same. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36KPkje079209; Tue, 6 Apr 2004 13:25:46 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36KPkpF079208; Tue, 6 Apr 2004 13:25:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36KPjVi079200 for ; Tue, 6 Apr 2004 13:25:45 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.20) id 1BAx8l-0001QI-4E for ietf-sasl@imc.org; Tue, 06 Apr 2004 22:25:47 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx6.uio.no with esmtp (Exim 4.30) id 1BAx8f-00059P-1C for ietf-sasl@imc.org; Tue, 06 Apr 2004 22:25:41 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BAx8e-0004mI-00 for ietf-sasl@imc.org; Tue, 6 Apr 2004 22:25:40 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: Re: Half-anonymous authentication In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 6 Apr 2004 22:25:40 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Uh... OTOH, on second reading of rfc2222bis, I can't see that a mechanism may make either ID anonymous at all. It was just so "obvious" that it could do so, that I didn't notice that it couldn't. Anyway, is that intended? I wrote: > As far as I can tell, a SASL authentication method may make the > authentication ID _or_ the authorization ID anonymous, but not the > other one. Also a bit unfortunate wording. Of course it may make both non-anonymous (or anonymous?) too:-) -- Hallvard Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36K5JPv077791; Tue, 6 Apr 2004 13:05:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36K5JKB077790; Tue, 6 Apr 2004 13:05:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36K5HEV077779 for ; Tue, 6 Apr 2004 13:05:18 -0700 (PDT) (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.20) id 1BAwox-00069T-4P for ietf-sasl@imc.org; Tue, 06 Apr 2004 22:05:19 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.30) id 1BAwov-0000V3-8N; Tue, 06 Apr 2004 22:05:17 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BAwou-0004jo-00; Tue, 6 Apr 2004 22:05:16 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: Half-anonymous authentication Date: Tue, 6 Apr 2004 22:05:16 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As far as I can tell, a SASL authentication method may make the authentication ID _or_ the authorization ID anonymous, but not the other one. Is that correct? Should it be correct? Non-anonymous authentication ID + anonymous authorization ID seems useful for the ANONYMOUS mechanism. Currently, servers that implement ANONYMOUS must make a special case to ensure that they don't give any access to apparently authenticated users who used this method. However, if ANONYMOUS sets the authorization ID to anonymous, servers will give anonymous access by default. That seems a lot safer, though whether it is a good idea or not depends on what the mechanism is intended to be used for. I suggested that some time ago, but got no response - it drowned in another subthread. OTOH, I can't think of a use for anonymous authentication ID with non-anonymous authorization ID, other than those which could just as well be fulfilled by setting the authentication ID as well. Like EXTERNAL. Don't know if that is any reason to forbid it, though. -- Hallvard