From owner-ietf-sasl Mon Dec 1 09:44:13 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1HiDib098345 for ; Mon, 1 Dec 2003 09:44:13 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB1HiD2H098344 for ietf-sasl-bks; Mon, 1 Dec 2003 09:44:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-ONE-O-NINE.MIT.EDU [18.187.5.109]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1HiAib098336 for ; Mon, 1 Dec 2003 09:44:12 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id A27F91515F2; Mon, 1 Dec 2003 12:44:09 -0500 (EST) To: ietf-sasl@imc.org Subject: Moving to rfc2222bis last call Message-Id: <20031201174409.A27F91515F2@konishi-polis.mit.edu> Date: Mon, 1 Dec 2003 12:44:09 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: What are we still waiting on before the next last call of this document? From owner-ietf-sasl Mon Dec 1 12:30:59 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1KUxib006007 for ; Mon, 1 Dec 2003 12:30:59 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB1KUxD8006006 for ietf-sasl-bks; Mon, 1 Dec 2003 12:30:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1KUwib005999 for ; Mon, 1 Dec 2003 12:30:58 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27449; Mon, 1 Dec 2003 15:30:46 -0500 (EST) Message-Id: <200312012030.PAA27449@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-crammd5-01.txt Date: Mon, 01 Dec 2003 15:30:46 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The CRAM-MD5 SASL Mechanism Author(s) : L. Nerenberg Filename : draft-ietf-sasl-crammd5-01.txt Pages : 7 Date : 2003-12-1 This document defines a simple challenge-response authentication mechanism, using a keyed-hash digest, for use with the Simple Authentication and Security Layer (SASL) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-crammd5-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-crammd5-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-1152419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-crammd5-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-crammd5-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-1152419.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Mon Dec 1 13:48:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1Lmbib008660 for ; Mon, 1 Dec 2003 13:48:37 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB1LmbYS008659 for ietf-sasl-bks; Mon, 1 Dec 2003 13:48:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1LmZib008654 for ; Mon, 1 Dec 2003 13:48:35 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hB1LmZlg001254; Mon, 1 Dec 2003 21:48:35 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031201131838.0426ae78@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 01 Dec 2003 13:47:40 -0800 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms Cc: Rob Siemborski , Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 07:16 PM 11/14/2003, Sam Hartman wrote: >One thing we need to keep in mind is that over time, we get a better >idea of what best practices for using SASL are. My operational experiences with LDAP show that making available a list of mechanisms post authentication isn't the "best" practice for preventing MITM downgrade attacks. I think the "best" practice is for the client and server to have policy which states what the levels of service are or are not acceptable (and when). A simple mechanism can just dictate minimum levels and refuse when not met. A more complex mechanism could have two levels, minimum and recommend, where less than recommended but higher than minimum required user authorization. I think the list mechanism approach in LDAP is a bit problematic. First, SASL (or other) security layers may not have been established making the information subject to MITM attack. Second, LDAP allows the list of mechanisms to change based upon current availability (to this client). It is possible that a stronger mechanism is, for legitimate reasons, no longer available. It is not possible for the client to deduce why a change in the listing was made. A more workable approach would be to recommend the server provide a list of mechanisms which WERE available to the client when it authenticated to the server. Lastly, the list doesn't prevent any similar MITM attacks (for example, downgrading of the cipher suites used by a listed mechanism). I also note that I have yet to find a client which actually uses the list of available mechanisms to detect MITM attacks. Clients which do attempt to detect such attacks tend to use a policy based mechanism. In short, I don't think we have enough good operational experience to add these imperatives to the technical specification. Kurt From owner-ietf-sasl Mon Dec 1 14:06:44 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1M6iib009754 for ; Mon, 1 Dec 2003 14:06:44 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB1M6i7b009753 for ietf-sasl-bks; Mon, 1 Dec 2003 14:06:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1M6hib009747 for ; Mon, 1 Dec 2003 14:06:43 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 1CDE71515F2; Mon, 1 Dec 2003 17:06:44 -0500 (EST) To: "Kurt D. Zeilenga" Cc: Rob Siemborski , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms References: <6.0.0.22.0.20031201131838.0426ae78@127.0.0.1> From: Sam Hartman Date: Mon, 01 Dec 2003 17:06:44 -0500 In-Reply-To: <6.0.0.22.0.20031201131838.0426ae78@127.0.0.1> (Kurt D. Zeilenga's message of "Mon, 01 Dec 2003 13:47:40 -0800") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> At 07:16 PM 11/14/2003, Sam Hartman wrote: >> One thing we need to keep in mind is that over time, we get a >> better idea of what best practices for using SASL are. Kurt> My operational experiences with LDAP show that making Kurt> available a list of mechanisms post authentication isn't the Kurt> "best" practice for preventing MITM downgrade attacks. Kurt> I think the "best" practice is for the client and server to Kurt> have policy which states what the levels of service are or Kurt> are not acceptable (and when). A simple mechanism can just Kurt> dictate minimum levels and refuse when not met. A more Kurt> complex mechanism could have two levels, minimum and Kurt> recommend, where less than recommended but higher than Kurt> minimum required user authorization. We all agree this is sufficient. However I believe that IETF experience with other security protocols strongly favors having a way to detect downgrades when possible. The problem is that in practice, people tend to establish fairly loose policies on their clients, so in situations where it is possible to detect the downgrade it is a good idea to do so. I agree there is not significant experience with this in the SASL community, but I believe there is sufficient experience in the SASL community to say that client policies do tend to be fairly lax and experience in the rest of the IETF to say that downgrade detection is desirable. I believe that is sufficient to provide advice for new protocols. From owner-ietf-sasl Mon Dec 1 14:40:04 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1Me4ib011085 for ; Mon, 1 Dec 2003 14:40:04 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB1Me4gL011084 for ietf-sasl-bks; Mon, 1 Dec 2003 14:40:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1Me0ib011076 for ; Mon, 1 Dec 2003 14:40:03 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.10/8.12.10) with ESMTP id hB1Me0rh017766 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 1 Dec 2003 23:40:01 +0100 To: ietf-sasl@imc.org Subject: draft-ietf-sasl-crammd5-01.txt From: Simon Josefsson X-Payment: hashcash 1.2 0:031201:ietf-sasl@imc.org:0b9356fad30d5eac X-Hashcash: 0:031201:ietf-sasl@imc.org:0b9356fad30d5eac Date: Mon, 01 Dec 2003 23:39:51 +0100 Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, I have read the document. Some comments: ,---- | The client MUST prepare the user name and shared secret strings | using the [SASLPrep] profile of the [StringPrep] algorithm. The | resulting values MUST be encoded as UTF-8 [UTF8]. `---- I suggest adding: The server MUST prepare the shared secret string using the [SASLPrep] profile of the [StringPrep] algorithm. The resulting value MUST be encoded as UTF-8 [UTF8]. The server may store the prepared string instead of, or as well as, the unprepared string, so that it does not have to prepare it every time it is needed for computation. However, if the original, unprepared string, is not stored, it may render the computed secret to be incompatible with a future revisions of SASLPrep that support currently unassigned code points (compare section 7 of [StringPrep]). It is therefor recommended to store the unprepared string in the database. Also, the example section is incorrect. Suggested new version: S: * OK [CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED AUTH=CRAM-MD5] C: A0001 AUTHENTICATE CRAM-MD5 S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UuZXhhbXBsZS5uZXQ+ C: am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3 S: A0001 OK CRAM-MD5 authentication successful In this example, the shared secret is the string tanstaaftanstaaf Hence, the Keyed MD5 digest is produced by calculating MD5((tanstaaftanstaaf XOR opad), MD5((tanstaaftanstaaf XOR ipad), <1896.697170952@postoffice.example.net>)) where ipad and opad are as defined in [KEYED-MD5] and the string shown in the challenge is the base64 encoding of <1896.697170952@postoffice.example.net>. The shared secret is null-padded to a length of 64 bytes. If the shared secret is longer than 64 bytes, the MD5 digest of the shared secret is used as a 16 byte input to the keyed MD5 calculation. This produces a digest value (in hexadecimal) of 3dbc88f0624776a737b39093f6eb6427 The user name is then prepended to it, forming joe 3dbc88f0624776a737b39093f6eb6427 Which is then base64 encoded to meet the requirements of the IMAP4 AUTHENTICATE command (or the similar POP3 AUTH command), yielding am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3 Perhaps it would be useful to add an example for non-ASCII strings too, using or similar to indicate non-ASCII characters. Thanks, Simon From owner-ietf-sasl Mon Dec 1 15:05:32 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1N5Vib011780 for ; Mon, 1 Dec 2003 15:05:31 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB1N5ViH011779 for ietf-sasl-bks; Mon, 1 Dec 2003 15:05:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB1N5Uib011773 for ; Mon, 1 Dec 2003 15:05:30 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa09435; 1 Dec 2003 18:05 EST Date: Mon, 01 Dec 2003 18:05:02 -0500 From: Jeffrey Hutzelman To: Simon Josefsson , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt Message-ID: <1753870000.1070319902@minbar.fac.cs.cmu.edu> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Monday, December 01, 2003 23:39:51 +0100 Simon Josefsson wrote: > I suggest adding: > > The server MUST prepare the shared secret string using the > [SASLPrep] profile of the [StringPrep] algorithm. The resulting > value MUST be encoded as UTF-8 [UTF8]. The server may store the > prepared string instead of, or as well as, the unprepared > string, so that it does not have to prepare it every time it is > needed for computation. However, if the original, unprepared > string, is not stored, it may render the computed secret to be > incompatible with a future revisions of SASLPrep that support > currently unassigned code points (compare section 7 of > [StringPrep]). It is therefor recommended to store the > unprepared string in the database. The correct way to handle this situation is to require that if the server stores the prepared string (or maybe, even if not), the server prepare the string with AllowUnassigned set to FALSE, thereby prohibiting unassigned code points. If the server stores the prepared string, then it is properly a "storage string" and should not be permitted to contain unassigned code points. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From owner-ietf-sasl Tue Dec 2 01:21:04 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB29L4ib097014 for ; Tue, 2 Dec 2003 01:21:04 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB29L4uT097013 for ietf-sasl-bks; Tue, 2 Dec 2003 01:21:04 -0800 (PST) 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.10/8.12.8) with ESMTP id hB29L2ib096982 for ; Tue, 2 Dec 2003 01:21:03 -0800 (PST) (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 1AR6iJ-00047Q-QW; Tue, 02 Dec 2003 10:20:59 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AR6iF-0003uh-T0; Tue, 02 Dec 2003 10:20:55 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AR6iF-0007Sa-00; Tue, 2 Dec 2003 10:20:55 +0100 From: Hallvard B Furuseth Message-Id: To: hartmans@mit.edu (Sam Hartman) Cc: ietf-sasl@imc.org Subject: Re: Moving to rfc2222bis last call In-Reply-To: <20031201174409.A27F91515F2@konishi-polis.mit.edu> References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 2 Dec 2003 10:20:55 +0100 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=-4.9, required 12, BAYES_00 -4.90) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: > What are we still waiting on before the next last call of this > document? I think this document needs another version before it is ready for last call. Here is the unfinished business I'm aware of: ------------------------------------------------------------------------ The 'suggested text about multiple SASL mechanisms' thread. ------------------------------------------------------------------------ Subject: [Fwd: Keeping/dropping existing SASL security layer] From: Alexey Melnikov Date: Tue, 11 Nov 2003 20:35:01 +0000 Message-ID: <3FB147F5.3070902@isode.com> URL: http://www.imc.org/ietf-sasl/mail-archive/msg01312.html Alexey's attack when keeping an old security layer. He sent it to Rob and me before the list, and I replied that I still did not understand, with a list of where I got lost. ------------------------------------------------------------------------ Subject: Re: rfc2222bis: re-negotiating SASL security layer From: Hallvard B Furuseth Date: Tue, 11 Nov 2003 22:24:45 +0100 Message-Id: URL: http://www.imc.org/ietf-sasl/mail-archive/msg01313.html When can a security layer be removed? What I said in this message seems to reflect what Alexey said last, but I don't quite think that's what he meant... ------------------------------------------------------------------------ Subject: Re: rfc2222bis: protocol profile? From: Hallvard B Furuseth Date: Mon, 10 Nov 2003 08:10:22 +0100 Message-Id: URL: http://www.imc.org/ietf-sasl/mail-archive/msg01304.html What belongs in the protocol profile? ------------------------------------------------------------------------ Subject: draft-ietf-sasl-rfc2222bis-02.txt section 4.2 From: Tony Hansen Date: Thu, 06 Nov 2003 12:02:22 -0500 Message-ID: <3FAA7E9E.3080704@att.com> URL: http://www.imc.org/ietf-sasl/mail-archive/msg01278.html Split section 4.2 (Authorization identities and proxy authentication). It appears to be mixing two totally different discussions together in a slightly confusing mess. ------------------------------------------------------------------------ The 'selects no security layer' thread. I've lost track of this one and will have to reread it. But originally all I wanted was to clarify that specific phrase: either to 'does not select a security layer' or 'selects that there shall be no security layer', or whatever else is meant. That has not been done yet. ------------------------------------------------------------------------ -- Hallvard From owner-ietf-sasl Tue Dec 2 11:31:23 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2JVMib036415 for ; Tue, 2 Dec 2003 11:31:23 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB2JVMRH036414 for ietf-sasl-bks; Tue, 2 Dec 2003 11:31:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2JVJib036406 for ; Tue, 2 Dec 2003 11:31:19 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 86F161515F2; Tue, 2 Dec 2003 14:31:20 -0500 (EST) To: Jeffrey Hutzelman Cc: Simon Josefsson , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Tue, 02 Dec 2003 14:31:20 -0500 In-Reply-To: <1753870000.1070319902@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Mon, 01 Dec 2003 18:05:02 -0500") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> The correct way to handle this situation is to require Jeffrey> that if the server stores the prepared string (or maybe, Jeffrey> even if not), the server prepare the string with Jeffrey> AllowUnassigned set to FALSE, thereby prohibiting Jeffrey> unassigned code points. If the server stores the Jeffrey> prepared string, then it is properly a "storage string" Jeffrey> and should not be permitted to contain unassigned code Jeffrey> points. I agree. I believe cram-md5 should always treat the secret as a storage string when it is updating its database. From owner-ietf-sasl Tue Dec 2 16:21:20 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB30LKib061041 for ; Tue, 2 Dec 2003 16:21:20 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB30LKv8061040 for ietf-sasl-bks; Tue, 2 Dec 2003 16:21:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB30LIib061034 for ; Tue, 2 Dec 2003 16:21:19 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.10/8.12.10) with ESMTP id hB30LGrh016695 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 3 Dec 2003 01:21:16 +0100 To: Sam Hartman Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Simon Josefsson X-Payment: hashcash 1.2 0:031203:hartmans@mit.edu:c80f5a86ea7835da X-Hashcash: 0:031203:hartmans@mit.edu:c80f5a86ea7835da X-Payment: hashcash 1.2 0:031203:jhutz@cmu.edu:16e069d1593831ca X-Hashcash: 0:031203:jhutz@cmu.edu:16e069d1593831ca X-Payment: hashcash 1.2 0:031203:ietf-sasl@imc.org:eb01571a02ef3851 X-Hashcash: 0:031203:ietf-sasl@imc.org:eb01571a02ef3851 Date: Wed, 03 Dec 2003 01:21:04 +0100 In-Reply-To: (Sam Hartman's message of "Tue, 02 Dec 2003 14:31:20 -0500") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: >>>>>> "Jeffrey" == Jeffrey Hutzelman writes: > > Jeffrey> The correct way to handle this situation is to require > Jeffrey> that if the server stores the prepared string (or maybe, > Jeffrey> even if not), the server prepare the string with > Jeffrey> AllowUnassigned set to FALSE, thereby prohibiting > Jeffrey> unassigned code points. If the server stores the > Jeffrey> prepared string, then it is properly a "storage string" > Jeffrey> and should not be permitted to contain unassigned code > Jeffrey> points. > > > I agree. I believe cram-md5 should always treat the secret as a > storage string when it is updating its database. I'm having trouble understanding what these statements imply for the protocol. Perhaps my trouble is because the discussion is now focused on the database, and not on the protocol. Do you mean that servers will be _required_ to use passwords prepared with AllowUnassigned false in the HMAC-MD5 computation? Regardless of whether the prepared string is ever stored in a database? If the answer is yes, I don't agree, because that would make CRAM-MD5 reject passwords containing characters introduced by Unicode 4.0.0. Regards, Simon PS. Forward compatibility issues with StringPrep profiles are discussed in the recent draft-faltstrom-unicode-synchronisation-00. From owner-ietf-sasl Tue Dec 2 20:10:48 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB34Amib068338 for ; Tue, 2 Dec 2003 20:10:48 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB34AmZP068337 for ietf-sasl-bks; Tue, 2 Dec 2003 20:10:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB34Akib068332 for ; Tue, 2 Dec 2003 20:10:46 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hB34Aelg023477; Wed, 3 Dec 2003 04:10:41 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031202193544.02757990@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 02 Dec 2003 20:09:44 -0800 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-sasl-crammd5-01.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 04:21 PM 12/2/2003, Simon Josefsson wrote: > Regardless of whether the prepared string is ever stored in a > database? First, I think "in a database" is a unnecessary qualification. All that matters is that it is a "stored" string per stringprep. In each of the password-based mechanisms (PLAIN, CRAM-MD5, DIGEST-MD5, etc.), the user provided string is clear a "query" string and the string which it is compared against (directly or indirectly) is a "stored" string (regardless of whether the server stores it locally or in some external systems). > Perhaps my trouble is because the discussion is now focused > on the database, and not on the protocol. I do think that it should be considered an implementation detail whether the server applies SASLprep with unassigned disallowed before or after use storage. What matters to the protocol/algorithm is the server apply the SASLprep with disallowed before comparison to the "stored" string. Generally, doing it before storage is more appropriate. However, there is no harm (and there may be advantage in some instances (e.g., external password stores)) of doing it after fetching it from storage (BUT before comparison). So, maybe we're agreeing... >If the answer is yes, I don't agree, because that would make CRAM-MD5 >reject passwords containing characters introduced by Unicode 4.0.0. As intended! Until stringprep is updated to detail how these newly assigned code points are to be handled, we need to exclude them from appearing in the "stored" password string. Kurt From owner-ietf-sasl Wed Dec 3 09:21:30 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3HLUib070096 for ; Wed, 3 Dec 2003 09:21:30 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3HLUGW070095 for ietf-sasl-bks; Wed, 3 Dec 2003 09:21:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-NINETEEN.MIT.EDU [18.187.5.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3HLSib070090 for ; Wed, 3 Dec 2003 09:21:28 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id AF9971515F2; Wed, 3 Dec 2003 12:21:28 -0500 (EST) To: Simon Josefsson Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Wed, 03 Dec 2003 12:21:28 -0500 In-Reply-To: (Simon Josefsson's message of "Wed, 03 Dec 2003 01:21:04 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Simon" == Simon Josefsson writes: Simon> I'm having trouble understanding what these statements Simon> imply for the protocol. Perhaps my trouble is because the Simon> discussion is now focused on the database, and not on the Simon> protocol. Simon> Do you mean that servers will be _required_ to use Simon> passwords prepared with AllowUnassigned false in the Simon> HMAC-MD5 computation? I mean that this should be a requirement for interoperability in the long term. If you don't have this requirement, then you may run into cases where saslprep eventually maps out those characters in the future. Basically, if we require allowunassigned to be false, we guarantee future interoperability at the cost of refusing to allow people to use unassigned characters until saslprep is updated. From owner-ietf-sasl Wed Dec 3 11:08:54 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3J8sib076615 for ; Wed, 3 Dec 2003 11:08:54 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3J8sQ7076614 for ietf-sasl-bks; Wed, 3 Dec 2003 11:08:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-NINETEEN.MIT.EDU [18.187.5.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3J8rib076608 for ; Wed, 3 Dec 2003 11:08:53 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 8ABAC1515F2; Wed, 3 Dec 2003 14:08:52 -0500 (EST) To: ietf-sasl@imc.org Subject: Draft Minutes for SASL working group meeting From: Sam Hartman Date: Wed, 03 Dec 2003 14:08:52 -0500 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please comment; I'll submit at the end of the week or the proceedings deadline, whichever is sooner. From: Philip Guenther Minutes for IETF 58 SASL Working Group scribe: Philip Guenther guenther@sendmail.com chairs: Sam Hartman , Kurt Zeilenga agenda change: - add short discussion of private-use characters in saslprep status of drafts: - base-spec last call was not discussed in previous meeting, but it has been last called since then - saslprep has been last called, but generated no comments at that time. fullstop issue arose after that - Alexey taking on editorship of gssapi mech draft - digests and cram-md5 updated to support stringprep - plain mech to be clarified. When applying saslprep, is a query string or a stored string, as that affects unassigned characters - example to be added showing no initial first reply - example to be added showing non-empty authorization ID - example to be added showing failure vs success - *not* to clarify SMTP usage or use SMTP instead of ACAP Rob Siemborski (speaking for Alexey): - 2222bis: - discussion of attack if the security layer is *not* dropped on reauthentication: - attack: - client authenticates to realm A (monitored by B) - reauthenticates to realm B w/o dropping the layer - realm B server now has an oracle on the confidentiality layer - the chairs noted that the risk of attack is related to the trust relationships in the server setup - poll of room re: how to handle - 15 to zero in favor of documenting in the security considerations and not altering the SASL requirement - the option of leaving it up to the protocol profile was considered by some to be an even worse choice due to the extra complexity it introduces. - will be taken to list for confirmation of consensus - consider adding text: client should check to verify that a MITM attack didn't remove mechanisms from the list by checking after - believed to be resolved with careful wording Kurt: - last call on saslprep draft - fullstop issue - some discussion on list - Ienup Sung presents: why fullstop != . - defs from unicode: - U+002E defined not just as period but also for decimals - U+3002 has U+002E as reference, not equivalence - U+FF0E (fullwidth period) *is* equivalent to U+002E - NFKC reflects this - ideographics stops are *only* used in text, not as decimal point (this is stricter in Japan and China than in Korea) - ergo: they should only be in the same equivalence class for internet style domain names (IDNA) and *not* in saslprep - - comments [confusing to follow] - Jeff Altman: - wording by Ienup seems to be that decimal *can* be used in text - therefore, *should* do mapping because users might not be able to control it - Marc Crispin:Please provide an example of a real world situation where this is a problem. - Paul Hoffman: - if you believe that normal names that will be used in sasl will include periods that will be used in context-sensitive ways, then do not to the mapping - Ienup: - feels that parens vs bracket in english is an analogous situations - Jeff Altman: - no, saslprep shouldn't always do the mapping; but that mechs should overide that for saslprep usages that specify things like domain-name-like items - Marc Crispin: - does not seem credibile that the mapping is necessary - wants credible example - Nico Williams: - felt that credible example was given, thinks that it may be a UI issue - private-use characters - suggestion by Jeff Altman that private-use char restriction should be removed and replaced with discussion of usages and lack of interoperability - characters not yet in unicode from previous charsets including experimental and those in internal use in corps - ?would require normalization of private-use characters? - Ienup: - saslprep prohibits them - some text cannot be entered without these - there is some need, understand problems and issues need to make clear that this is limited use - Kurt: - cannot just drop prohibition because too much is defined privately - chair: show of hands to go forward with even considering - 4 hands for - 5 hands against - Michel: - extremely bad idea - no semantic defined - not stable - even inside same organization, different usages may exist - no temporal stability - Paul Hoffman: - all that, plus, this is for identifiers and password only - name that requires private use character is unlikely - will be taken back to the list - Rob: SMTP AUTH - proposal to add initial response to IMAP - issue is in the rfcs, it's just not clear - new pop3 and smtp profile drafts - cleanup, add examples, fill in gaps - especially cases showing failing to send initial response - consensus on list was to *not* change examples in sasl plain from ACAP to SMTP - examples of initial client response and server last challenge *will* be added to rfc2222bis - WG wrap up - milestones - GSSAPI I-D is still missing, Alexey says new version should be out by end of November - implementation report to be pushed out because recycling at proposed - (or maybe not? chairs to discuss); base may not need recycling - base is ready for last call - plain has minor tweaks, needs last call - anonymous is ready - saslprep has minor issues - cram-md5 and digest-md5 need a little more work before last call Alexey has dealt with CBC issues but missed cut-off before meeting - base, plain, anonymous, and saslprep before end of year - digest + cram shortly thereafter - gssapi by, say, May? - Bob Morgan - FYI: OASIS has interest in defining a SASL mech doing single-sign-on expect note to mailing list From owner-ietf-sasl Wed Dec 3 11:17:41 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3JHfib076872 for ; Wed, 3 Dec 2003 11:17:41 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3JHf06076871 for ietf-sasl-bks; Wed, 3 Dec 2003 11:17:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-NINETEEN.MIT.EDU [18.187.5.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3JHeib076864 for ; Wed, 3 Dec 2003 11:17:40 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id B1E9D1515F2; Wed, 3 Dec 2003 14:17:39 -0500 (EST) To: Simon Josefsson Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Wed, 03 Dec 2003 14:17:39 -0500 In-Reply-To: (Simon Josefsson's message of "Wed, 03 Dec 2003 19:56:03 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Simon" == Simon Josefsson writes: Simon> If SASLPrepX is guaranteed to behave the same as SASLPrep Simon> for currently assigned characters, there is no problem in Simon> storing SASLPrep prepared strings in the database, and my Simon> text is incorrect. However, in that case, I believe the Simon> guarantee that SASLPrepX(SASLPrep(string)) = Simon> SASLPrepX(string) should be stated in the SASLPrep Simon> document. I believe this guarantee is stated in stringprep. From owner-ietf-sasl Wed Dec 3 11:35:53 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3JZrib077631 for ; Wed, 3 Dec 2003 11:35:53 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3JZruM077630 for ietf-sasl-bks; Wed, 3 Dec 2003 11:35:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3JZpib077624 for ; Wed, 3 Dec 2003 11:35:52 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.10/8.12.10) with ESMTP id hB3JZkrh005664 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 3 Dec 2003 20:35:46 +0100 To: Sam Hartman Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Simon Josefsson X-Payment: hashcash 1.2 0:031203:hartmans@mit.edu:4929e304894508c6 X-Hashcash: 0:031203:hartmans@mit.edu:4929e304894508c6 X-Payment: hashcash 1.2 0:031203:jhutz@cmu.edu:a6a81735d4c0c035 X-Hashcash: 0:031203:jhutz@cmu.edu:a6a81735d4c0c035 X-Payment: hashcash 1.2 0:031203:ietf-sasl@imc.org:90616f6c18f9afc5 X-Hashcash: 0:031203:ietf-sasl@imc.org:90616f6c18f9afc5 Date: Wed, 03 Dec 2003 20:35:33 +0100 In-Reply-To: (Sam Hartman's message of "Wed, 03 Dec 2003 14:17:39 -0500") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: >>>>>> "Simon" == Simon Josefsson writes: > > Simon> If SASLPrepX is guaranteed to behave the same as SASLPrep > Simon> for currently assigned characters, there is no problem in > Simon> storing SASLPrep prepared strings in the database, and my > Simon> text is incorrect. However, in that case, I believe the > Simon> guarantee that SASLPrepX(SASLPrep(string)) = > Simon> SASLPrepX(string) should be stated in the SASLPrep > Simon> document. > > I believe this guarantee is stated in stringprep. I'm sorry to be dense, but can you be more specific? I thought future stringprep profiles were allowed to use Unicode 4.0.0, including the correct normalization tables, but if SASLPrep2 would do so, the above guarantee doesn't hold. Thanks, Simon From owner-ietf-sasl Wed Dec 3 11:43:31 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3JhVib077914 for ; Wed, 3 Dec 2003 11:43:31 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3JhVRc077913 for ietf-sasl-bks; Wed, 3 Dec 2003 11:43:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-NINETEEN.MIT.EDU [18.187.5.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3JhUib077907 for ; Wed, 3 Dec 2003 11:43:30 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id A35FB1515F2; Wed, 3 Dec 2003 14:43:29 -0500 (EST) To: Simon Josefsson Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Wed, 03 Dec 2003 14:43:29 -0500 In-Reply-To: (Simon Josefsson's message of "Wed, 03 Dec 2003 20:35:33 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Simon" == Simon Josefsson writes: Simon> I'm sorry to be dense, but can you be more specific? I Simon> thought future stringprep profiles were allowed to use Simon> Unicode 4.0.0, including the correct normalization tables, Simon> but if SASLPrep2 would do so, the above guarantee doesn't Simon> hold. The problem here being that normalization changed between 3.2 and 4.0 in incompatible ways? Well, that's sort of an open issue within the IETF because that wasn't supposed to happen. Stringprep assumes normalization never changes; we assume that future versions of stringprep onlly change in handling of unassigned codepoints. Unicode has created a mess for us and we have not decided how to deal. From owner-ietf-sasl Wed Dec 3 10:56:22 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3IuMib076217 for ; Wed, 3 Dec 2003 10:56:22 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3IuMVN076216 for ietf-sasl-bks; Wed, 3 Dec 2003 10:56:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3IuKib076197 for ; Wed, 3 Dec 2003 10:56:20 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.10/8.12.10) with ESMTP id hB3IuGrh004892 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 3 Dec 2003 19:56:16 +0100 To: Sam Hartman Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Simon Josefsson X-Payment: hashcash 1.2 0:031203:hartmans@mit.edu:0dcae58eca711d66 X-Hashcash: 0:031203:hartmans@mit.edu:0dcae58eca711d66 X-Payment: hashcash 1.2 0:031203:jhutz@cmu.edu:ab1890be4cc6d30a X-Hashcash: 0:031203:jhutz@cmu.edu:ab1890be4cc6d30a X-Payment: hashcash 1.2 0:031203:ietf-sasl@imc.org:82b60170ff38f502 X-Hashcash: 0:031203:ietf-sasl@imc.org:82b60170ff38f502 Date: Wed, 03 Dec 2003 19:56:03 +0100 In-Reply-To: (Sam Hartman's message of "Wed, 03 Dec 2003 12:21:28 -0500") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: > I mean that this should be a requirement for interoperability in the > long term. If you don't have this requirement, then you may run into > cases where saslprep eventually maps out those characters in the > future. > > Basically, if we require allowunassigned to be false, we guarantee > future interoperability at the cost of refusing to allow people to use > unassigned characters until saslprep is updated. I don't see a conflict with this and the text I proposed, but I'm not sure if you argue for or against the text. In fact, the problem of forward compatible databases was the motivation for my text. The text would help if SASLPrepX(SASLPrep(string)) != SASLPrepX(string) where SASLPrepX is any future revision of SASLPrep. If SASLPrepX is guaranteed to behave the same as SASLPrep for currently assigned characters, there is no problem in storing SASLPrep prepared strings in the database, and my text is incorrect. However, in that case, I believe the guarantee that SASLPrepX(SASLPrep(string)) = SASLPrepX(string) should be stated in the SASLPrep document. "Kurt D. Zeilenga" writes: > In each of the password-based mechanisms (PLAIN, CRAM-MD5, > DIGEST-MD5, etc.), the user provided string is clear a "query" > string and the string which it is compared against (directly > or indirectly) is a "stored" string (regardless of whether > the server stores it locally or in some external systems). This is not the only interpretation. It is possible to consider the SASL library to be performing a query against the HMAC-MD5 oracle to decide whether a Unicode string the library received from the application (possibly ultimately from a database), after the library has prepared it with SASLPrep with AllowUnassigned set to true, is the same secret used by the client. >>If the answer is yes, I don't agree, because that would make CRAM-MD5 >>reject passwords containing characters introduced by Unicode 4.0.0. > > As intended! Until stringprep is updated to detail how these > newly assigned code points are to be handled, we need to exclude > them from appearing in the "stored" password string. The behaviour of inputting Unicode 4.0.0 characters should still be well defined. The current text say nothing about what the server should do, so rejecting the input isn't the only alternative. Thanks, Simon From owner-ietf-sasl Wed Dec 3 12:34:24 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3KYOib080168 for ; Wed, 3 Dec 2003 12:34:24 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3KYONp080167 for ietf-sasl-bks; Wed, 3 Dec 2003 12:34:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3KYMib080162 for ; Wed, 3 Dec 2003 12:34:22 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.10/8.12.10) with ESMTP id hB3KYKrh006966 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 3 Dec 2003 21:34:21 +0100 To: Sam Hartman Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Simon Josefsson X-Payment: hashcash 1.2 0:031203:hartmans@mit.edu:f03ce38d97c49e19 X-Hashcash: 0:031203:hartmans@mit.edu:f03ce38d97c49e19 X-Payment: hashcash 1.2 0:031203:jhutz@cmu.edu:80f7ade3ca434606 X-Hashcash: 0:031203:jhutz@cmu.edu:80f7ade3ca434606 X-Payment: hashcash 1.2 0:031203:ietf-sasl@imc.org:e81851d0b8e5db8d X-Hashcash: 0:031203:ietf-sasl@imc.org:e81851d0b8e5db8d Date: Wed, 03 Dec 2003 21:34:08 +0100 In-Reply-To: (Sam Hartman's message of "Wed, 03 Dec 2003 14:43:29 -0500") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: >>>>>> "Simon" == Simon Josefsson writes: > > > Simon> I'm sorry to be dense, but can you be more specific? I > Simon> thought future stringprep profiles were allowed to use > Simon> Unicode 4.0.0, including the correct normalization tables, > Simon> but if SASLPrep2 would do so, the above guarantee doesn't > Simon> hold. > > The problem here being that normalization changed between 3.2 and 4.0 > in incompatible ways? That's one example of the problem, yes. In general, I didn't find any guarantee that a future version of a stringprep profile must be backwards compatible to the previous version. For SASLPrep, that could be useful, but I haven't found any place that say it must be so. If there isn't, storing the unprepared string in databases appear to be the safe recommendation. (It might be anyway, if the database is shared with other password infrastructures that doesn't use SASLPrep, but that's besides the point.) Thanks, Simon From owner-ietf-sasl Wed Dec 3 12:36:42 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3Kagib080248 for ; Wed, 3 Dec 2003 12:36:42 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3Kagbh080247 for ietf-sasl-bks; Wed, 3 Dec 2003 12:36:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-NINETEEN.MIT.EDU [18.187.5.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3Kafib080242 for ; Wed, 3 Dec 2003 12:36:41 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 92F411515F2; Wed, 3 Dec 2003 15:36:37 -0500 (EST) To: Simon Josefsson Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Wed, 03 Dec 2003 15:36:37 -0500 In-Reply-To: (Simon Josefsson's message of "Wed, 03 Dec 2003 21:34:08 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Simon" == Simon Josefsson writes: Simon> Sam Hartman writes: >>>>>>> "Simon" == Simon Josefsson writes: >> Simon> I'm sorry to be dense, but can you be more specific? I Simon> thought future stringprep profiles were allowed to use Simon> Unicode 4.0.0, including the correct normalization tables, Simon> but if SASLPrep2 would do so, the above guarantee doesn't Simon> hold. >> The problem here being that normalization changed between 3.2 >> and 4.0 in incompatible ways? Simon> That's one example of the problem, yes. In general, I Simon> didn't find any guarantee that a future version of a Simon> stringprep profile must be backwards compatible to the Simon> previous version. For SASLPrep, that could be useful, but Simon> I haven't found any place that say it must be so. If there Simon> isn't, storing the unprepared string in databases appear to Simon> be the safe recommendation. (It might be anyway, if the Simon> database is shared with other password infrastructures that Simon> doesn't use SASLPrep, but that's besides the point.) It's my understanding that the entire IETF internationalization architecture as it depends on stringprep depends on this guarantee. Sort of unfortunate that it is not stated. From owner-ietf-sasl Wed Dec 3 13:06:50 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3L6oib081477 for ; Wed, 3 Dec 2003 13:06:50 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3L6oRM081476 for ietf-sasl-bks; Wed, 3 Dec 2003 13:06:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3L6nib081471 for ; Wed, 3 Dec 2003 13:06:49 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hB3L6glg033478; Wed, 3 Dec 2003 21:06:42 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031203123841.02784828@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 03 Dec 2003 13:05:45 -0800 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-sasl-crammd5-01.txt Cc: Sam Hartman , Jeffrey Hutzelman , ietf-sasl@imc.org In-Reply-To: References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:56 AM 12/3/2003, Simon Josefsson wrote: >"Kurt D. Zeilenga" writes: > >> In each of the password-based mechanisms (PLAIN, CRAM-MD5, >> DIGEST-MD5, etc.), the user provided string is clear a "query" >> string and the string which it is compared against (directly >> or indirectly) is a "stored" string (regardless of whether >> the server stores it locally or in some external systems). > >This is not the only interpretation. It is possible to consider the >SASL library to be performing a query against the HMAC-MD5 oracle to >decide whether a Unicode string the library received from the >application (possibly ultimately from a database), after the library >has prepared it with SASLPrep with AllowUnassigned set to true, is the >same secret used by the client. Well, maybe the language I used was not clear enough. My point is that the mechanism specification must clearly state which strings are query strings and which strings are stored strings and ensure that two query strings prepared by different implementations are not (directly or indirectly) compared. The client copy of the user name and shared secret should be defined as query strings and, hence, unassigned code points are allowed to appear in the prepared output. The server copy of the user name and shared secret should be viewed as stored strings and, hence, unassigned code points are not allowed to appear in the prepared output. The draft needs to be revised to make this clear. Kurt From owner-ietf-sasl Wed Dec 3 13:36:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3LaYib082725 for ; Wed, 3 Dec 2003 13:36:34 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3LaY4I082724 for ietf-sasl-bks; Wed, 3 Dec 2003 13:36:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3LaWib082719 for ; Wed, 3 Dec 2003 13:36:32 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hB3LaX5G028697; Wed, 3 Dec 2003 16:36:33 -0500 Date: Wed, 3 Dec 2003 16:36:33 -0500 (EST) From: Rob Siemborski To: Sam Hartman cc: ietf-sasl@imc.org Subject: Re: Moving to rfc2222bis last call In-Reply-To: <20031201174409.A27F91515F2@konishi-polis.mit.edu> Message-ID: References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 1 Dec 2003, Sam Hartman wrote: > What are we still waiting on before the next last call of this > document? >From the minutes, we need to see an updated security considerations section (for the MITM attack), and we need examples for the initial client response and server last sends. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Wed Dec 3 14:28:20 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3MSJib086040 for ; Wed, 3 Dec 2003 14:28:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3MSJka086039 for ietf-sasl-bks; Wed, 3 Dec 2003 14:28:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3MSIib086034 for ; Wed, 3 Dec 2003 14:28:18 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hB3MSKlg034367 for ; Wed, 3 Dec 2003 22:28:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031203141404.0913d728@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 03 Dec 2003 14:27:23 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: PLAIN and unassigned characters (Was: draft-ietf-sasl-crammd5-01.txt) In-Reply-To: <6.0.0.22.0.20031203123841.02784828@127.0.0.1> References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> <6.0.0.22.0.20031203123841.02784828@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: In consideration of the on-going CRAM-MD5 unassigned code point discussions, I reviewed draft-ietf-sasl-plain-xx.txt handling in this area and found that a few additional words would add clarity in this area. Hence, I'd like to make the following change: @@ -151,10 +151,12 @@ The presented authentication identity and password strings are not to be compared directly with stored strings. The server SHALL first prepare authentication identity and password strings using the [SASLPrep] profile of the [StringPrep] algorithm. +Per Section 7 of [StringPrep], unassigned code points may appear in +prepared presented (query) strings but are prohibited in stored strings. If preparation fails or results in an empty string, verification SHALL fail. If the server stores only the hash of expected string, the string MUST be prepared before generation of the hash. (+ indicates new text) Additionally (as previously discussed), I'll update the pseudo code such that SASLprep() takes a second argument as follows: +The second parameter of the SASLprep function, when true, indicates +that the input string is a "query" string [StringPrep] and, hence, +unassigned code points are allowed. When the SASLprep function is +called to prepared the password prior to computing the stored hash, +the second parameter would be false as unassigned code points are +not allowed in "stored strings" [StringPrep]. Kurt At 01:05 PM 12/3/2003, Kurt D. Zeilenga wrote: >At 10:56 AM 12/3/2003, Simon Josefsson wrote: >>"Kurt D. Zeilenga" writes: >> >>> In each of the password-based mechanisms (PLAIN, CRAM-MD5, >>> DIGEST-MD5, etc.), the user provided string is clear a "query" >>> string and the string which it is compared against (directly >>> or indirectly) is a "stored" string (regardless of whether >>> the server stores it locally or in some external systems). >> >>This is not the only interpretation. It is possible to consider the >>SASL library to be performing a query against the HMAC-MD5 oracle to >>decide whether a Unicode string the library received from the >>application (possibly ultimately from a database), after the library >>has prepared it with SASLPrep with AllowUnassigned set to true, is the >>same secret used by the client. > >Well, maybe the language I used was not clear enough. > >My point is that the mechanism specification must clearly >state which strings are query strings and which strings are >stored strings and ensure that two query strings prepared >by different implementations are not (directly or indirectly) >compared. > >The client copy of the user name and shared secret should >be defined as query strings and, hence, unassigned code points >are allowed to appear in the prepared output. The server >copy of the user name and shared secret should be viewed >as stored strings and, hence, unassigned code points are not >allowed to appear in the prepared output. > >The draft needs to be revised to make this clear. > >Kurt From owner-ietf-sasl Wed Dec 3 15:36:04 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3Na3ib088696 for ; Wed, 3 Dec 2003 15:36:03 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3Na3sT088695 for ietf-sasl-bks; Wed, 3 Dec 2003 15:36:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3Na0ib088689 for ; Wed, 3 Dec 2003 15:36:02 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hB3Na2lg035083 for ; Wed, 3 Dec 2003 23:36:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031203153456.09152800@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 03 Dec 2003 15:35:04 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: PLAIN 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: Here are the updated examples section: This section provides examples of PLAIN authentication exchanges. The examples are intended to help the readers understand the above text. The examples are not definitive. "C:" and "S:" indicate lines sent by the client and server respectively. "" represents a single NUL (U+0000) character. The Application Configuration Access Protocol ([ACAP]) is used in the examples. The first example shows how the PLAIN mechanism might be used for user authentication. S: * ACAP (SASL "CRAM-MD5") (STARTTLS) C: a001 STARTTLS S: a001 OK "Begin TLS negotiation now" S: * ACAP (SASL "CRAM-MD5" "PLAIN") C: a002 AUTHENTICATE "PLAIN" S: + "" C: {21} C: timtanstaaftanstaaf S: a002 OK "Authenticated" The second example shows how the PLAIN mechanism might be used to assuming the identity of another user. In this example, the server rejects the request. Also, this example makes use of the protocol optional initial response capability to eliminate a round-trip. S: * ACAP (SASL "CRAM-MD5") (STARTTLS) C: a001 STARTTLS S: a001 OK "Begin TLS negotiation now" S: * ACAP (SASL "CRAM-MD5" "PLAIN") C: a002 AUTHENTICATE "PLAIN" {19+} C: JaneJohnxipj3plmq S: a002 NO "Not authorized to assume asserted identity" From owner-ietf-sasl Wed Dec 3 15:37:56 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3Nbuib088745 for ; Wed, 3 Dec 2003 15:37:56 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3Nbu1k088744 for ietf-sasl-bks; Wed, 3 Dec 2003 15:37:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB3Nbsib088739 for ; Wed, 3 Dec 2003 15:37:55 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa14075; 3 Dec 2003 18:37 EST Date: Wed, 03 Dec 2003 18:37:13 -0500 From: Jeffrey Hutzelman To: Simon Josefsson , Sam Hartman cc: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt Message-ID: <58040000.1070494633@minbar.fac.cs.cmu.edu> In-Reply-To: References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wednesday, December 03, 2003 19:56:03 +0100 Simon Josefsson wrote: > I don't see a conflict with this and the text I proposed, but I'm not > sure if you argue for or against the text. In fact, the problem of > forward compatible databases was the motivation for my text. The text > would help if SASLPrepX(SASLPrep(string)) != SASLPrepX(string) where > SASLPrepX is any future revision of SASLPrep. Yeah; that's supposed to be a guarantee. Part of this is spelled out in RFC2454, at the end of section 3 and in section 7.1: Authors of profiles of this document need to consider the effects of changing the mapping of any currently-assigned character when updating their profiles. Adding a new mapping for a currently- assigned character, or changing an existing mapping, could cause a variance between the behavior of systems that have been updated and systems that have not been updated. A subsequent version of a profile that references a newer version of a repertoire with new code points will inherently have some code points move from category U to either D, MN, or AO. For backwards compatibility, a subsequent version of a profile MUST NOT move code points from any other category. That is, current AO, MN, or D code points MUST NOT ever change to a different category. The rest comes from Unicode itself, which guarantees that normalizations for existing code points will not change. Sadly, it appears the UTC has been willing to violate that guarantee in some cases. > This is not the only interpretation. It is possible to consider the > SASL library to be performing a query against the HMAC-MD5 oracle to > decide whether a Unicode string the library received from the > application (possibly ultimately from a database), after the library > has prepared it with SASLPrep with AllowUnassigned set to true, is the > same secret used by the client. This critical issue is that for servers where a partial MD5 context is stored based on the shared secret, the secret MUST first be prepared according to SASLprep. In this case, the secret needs to be treated as a storage string -- there's no way to reverse the context establishment, so if the string was not normalized correctly to begin with, you can't go back and fix it when you upgrade. Thus, unassigned code points MUST NOT be permitted in such a case. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA > >>> If the answer is yes, I don't agree, because that would make CRAM-MD5 >>> reject passwords containing characters introduced by Unicode 4.0.0. >> >> As intended! Until stringprep is updated to detail how these >> newly assigned code points are to be handled, we need to exclude >> them from appearing in the "stored" password string. > > The behaviour of inputting Unicode 4.0.0 characters should still be > well defined. The current text say nothing about what the server > should do, so rejecting the input isn't the only alternative. > > Thanks, > Simon > > > From owner-ietf-sasl Thu Dec 4 11:13:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4JDYib017771 for ; Thu, 4 Dec 2003 11:13:34 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB4JDYcc017770 for ietf-sasl-bks; Thu, 4 Dec 2003 11:13:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4JDWib017761 for ; Thu, 4 Dec 2003 11:13:32 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.9) with ESMTP id hB4JDY50001433 for ; Thu, 4 Dec 2003 19:13:34 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031204105707.03c7d860@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 04 Dec 2003 11:12:35 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Proposed new slate of milestones for SASL WG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The chairs propose updating our slate of milestones to: Done Submit revised SASL (+ EXTERNAL) I-D Done Submit revised SASL ANONYMOUS I-D Done Submit revised SASL PLAIN I-D Done Submit revised SASL CRAM-MD5 I-D Done Submit revised SASL DIGEST-MD5 I-D Done Submit revised SASL GSSAPI I-D Jan 04 Submit SASL (+ EXTERNAL), SASLprep, ANONYMOUS, PLAIN to IESG for consideration as Proposed Standards Feb 04 Submit CRAM-MD5 to IESG for consideration as a Proposed Standard Mar 04 Submit DIGEST-MD5 to IESG for consideration as a Proposed Standard May 04 Submit GSSAPI to IESG for consideration as a Proposed Standard Jun 04 Provide implementation report plan (with milestones) Aug 04 Revise charter or conclude Note that the milestone dates are basically those suggested at IETF#58 but slipped a month or so. Note as well that this slate calls for all of the revised SASL specifications, including the rfc2222bis I-D, to be recycled at Proposed. This is mainly due to the introduction of SASLprep (which even the rfc2222bis I-D normatively references). If you have comments/concerns regarding this slate, please post them within the next week or so. The chairs plan on making a decision regarding what slate of milestones to progressed to our AD by 19th of this month. Kurt, SASL WG co-chair From owner-ietf-sasl Thu Dec 4 18:21:50 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB52Loib038132 for ; Thu, 4 Dec 2003 18:21:50 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB52LoSW038131 for ietf-sasl-bks; Thu, 4 Dec 2003 18:21:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB52Lmib038123 for ; Thu, 4 Dec 2003 18:21:49 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from [192.168.1.102] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id hB52Lm40007250; Thu, 4 Dec 2003 19:21:49 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Thu, 04 Dec 2003 18:21:45 -0800 From: Lyndon Nerenberg To: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: PLAIN examples Message-ID: <2147483647.1070562105@[192.168.42.6]> In-Reply-To: <6.0.0.22.0.20031203153456.09152800@127.0.0.1> References: <6.0.0.22.0.20031203153456.09152800@127.0.0.1> X-Mailer: Mulberry/3.1.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on orthanc.ca Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > C: JaneJohnxipj3plmq I would change Jane and John to something not quite so similar, just to make the distinction more obvious. --lyndon From owner-ietf-sasl Thu Dec 4 19:07:33 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB537Xib040211 for ; Thu, 4 Dec 2003 19:07:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB537XJX040210 for ietf-sasl-bks; Thu, 4 Dec 2003 19:07:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB537Tib040204 for ; Thu, 4 Dec 2003 19:07:31 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from [192.168.1.102] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id hB537M40007527; Thu, 4 Dec 2003 20:07:23 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Thu, 04 Dec 2003 19:07:19 -0800 From: Lyndon Nerenberg To: "Kurt D. Zeilenga" , Simon Josefsson cc: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt Message-ID: <2147483647.1070564839@[192.168.42.6]> In-Reply-To: <6.0.0.22.0.20031203123841.02784828@127.0.0.1> References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> <6.0.0.22.0.20031203123841.02784828@127.0.0.1> X-Mailer: Mulberry/3.1.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on orthanc.ca Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Wednesday, December 3, 2003 1:05 PM -0800 "Kurt D. Zeilenga" wrote: > The client copy of the user name and shared secret should > be defined as query strings and, hence, unassigned code points > are allowed to appear in the prepared output. The server > copy of the user name and shared secret should be viewed > as stored strings and, hence, unassigned code points are not > allowed to appear in the prepared output. > > The draft needs to be revised to make this clear. I'm having no luck coming up with text that explains this clearly. And I'm still not convinced that this should be discussed in the mechanism spec, since it applies much more widely than just CRAM. 2222bis seems to me to be a better place to lay this out. That said, I have to rev the CRAM draft again for other (editorial) reasons, so if someone can come up with a diff to -01 I'll incorporate it. (Or is Kurt's paragraph above clear enough?) --lyndon From owner-ietf-sasl Fri Dec 5 04:19:35 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5CJZib037545 for ; Fri, 5 Dec 2003 04:19:35 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5CJYWv037544 for ietf-sasl-bks; Fri, 5 Dec 2003 04:19:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5CJSib037537 for ; Fri, 5 Dec 2003 04:19:34 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.253]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Fri, 5 Dec 2003 12:23:00 +0000 Message-ID: <3FD077CB.9090101@isode.com> Date: Fri, 05 Dec 2003 12:19:23 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Moving to rfc2222bis last call References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> In-Reply-To: <20031201174409.A27F91515F2@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: >What are we still waiting on before the next last call of this >document? > Rob's assessment is right. I also need to work on some issues raised by Hallvard. I am a bit busy at the moment. I will try to push a new revision in a week or so. Alexey From owner-ietf-sasl Fri Dec 5 08:14:45 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5GEjib050166 for ; Fri, 5 Dec 2003 08:14:45 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5GEjER050165 for ietf-sasl-bks; Fri, 5 Dec 2003 08:14:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-NINETEEN.MIT.EDU [18.187.5.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5GEhib050158 for ; Fri, 5 Dec 2003 08:14:43 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 15DA71515F2; Fri, 5 Dec 2003 11:14:38 -0500 (EST) To: Lyndon Nerenberg Cc: "Kurt D. Zeilenga" , Simon Josefsson , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> <6.0.0.22.0.20031203123841.02784828@127.0.0.1> <2147483647.1070564839@[192.168.42.6]> From: Sam Hartman Date: Fri, 05 Dec 2003 11:14:38 -0500 In-Reply-To: <2147483647.1070564839@[192.168.42.6]> (Lyndon Nerenberg's message of "Thu, 04 Dec 2003 19:07:19 -0800") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Lyndon" == Lyndon Nerenberg writes: Lyndon> I'm having no luck coming up with text that explains this Lyndon> clearly. And I'm still not convinced that this should be Lyndon> discussed in the mechanism spec, since it applies much Lyndon> more widely than just CRAM. 2222bis seems to me to be a Lyndon> better place to lay this out. I disagree. How to prepare authentication identities is entirely a mechanism matter. The base spec can point out the general concern but cannot constrain what the mechanism does. For example various GSSAPI mechanisms may do much more complicated stringprep. Kerberos certainly will. From owner-ietf-sasl Fri Dec 5 20:33:43 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB64Xhib089893 for ; Fri, 5 Dec 2003 20:33:43 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB64XhE5089892 for ietf-sasl-bks; Fri, 5 Dec 2003 20:33:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB64Xfib089887 for ; Fri, 5 Dec 2003 20:33:41 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.9) with ESMTP id hB64Xia9025211 for ; Sat, 6 Dec 2003 04:33:44 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031205203112.027483c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 05 Dec 2003 20:32:43 -0800 To: ietf-sasl@imc.org From: "Sebastian Petrescu" Subject: sasl + pam : ietf-sasl 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: Hello. I do have a problem. I'm trying to install postfix + sasl with pam support. saslauthd -v saslauthd 2.1.17 authentication mechanisms: getpwent rimap shadow I do have pam installed on my system .. and I'v vonfigured sasl: ./configure --prefix=3D/usr --enable-anon --enable-plain --enable-login --disable-krb4 --with-pam --with-saslauthd=3D/var/run/saslauthd = --with-plugindir=3D/usr/lib/sasl2 --libdir=3D/usr/lib/sasl2 = --with-plugindir=3D/usr/lib/sasl2 |grep pam configure: WARNING: Disabling GSSAPI - no include files found configure: running /bin/sh './configure' --prefix=3D/usr/local '--enable-anon' '--enable-plain' '--enable-login' '--disable-krb4' '--with-saslauthd=3D/var/run/saslauthd' '--libdir=3D/usr/lib/sasl2' '--with-plugindir=3D/usr/lib/sasl2' '--with-pam=3D/lib/security' --cache-file=3D.././config.cache --srcdir=3D. configure: WARNING: Disabling GSSAPI - no include files found checking for pam_start in -lpam... (cached) no I do have pam installed.. I have recompiled pam and installed latest libraries. Can someone please give me a hint ? From owner-ietf-sasl Fri Dec 5 21:10:19 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB65AJib091480 for ; Fri, 5 Dec 2003 21:10:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB65AJDJ091479 for ietf-sasl-bks; Fri, 5 Dec 2003 21:10:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB65AIib091474 for ; Fri, 5 Dec 2003 21:10:18 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.9) with ESMTP id hB65ALa9025553; Sat, 6 Dec 2003 05:10:21 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031205210329.026fd4f0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 05 Dec 2003 21:09:20 -0800 To: "Sebastian Petrescu" From: "Kurt D. Zeilenga" Subject: Re: sasl + pam : ietf-sasl Cc: ietf-sasl@imc.org In-Reply-To: <6.0.0.22.0.20031205203112.027483c8@127.0.0.1> References: <6.0.0.22.0.20031205203112.027483c8@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: Sebastian, Your post is off-topic. This list is reserved for discussions related to the standardization of SASL. Your post would more appropriately be directed to list specific to the software you are using. It appears you are using Cyrus SASL, hence I suggest you direct your enquiry to lists.andrew.cmu.edu>. Kurt, IETF SASL WG Co-chair At 08:32 PM 12/5/2003, Sebastian Petrescu wrote: > Hello. > I do have a problem. I'm trying to install postfix + sasl with pam support. >saslauthd -v >saslauthd 2.1.17 >authentication mechanisms: getpwent rimap shadow > >I do have pam installed on my system .. and I'v vonfigured sasl: >./configure --prefix=3D/usr --enable-anon --enable-plain --enable-login --disable-krb4 --with-pam --with-saslauthd=3D/var/run/saslauthd = >--with-plugindir=3D/usr/lib/sasl2 --libdir=3D/usr/lib/sasl2 = >--with-plugindir=3D/usr/lib/sasl2 |grep pam > >configure: WARNING: Disabling GSSAPI - no include files found >configure: running /bin/sh './configure' --prefix=3D/usr/local '--enable-anon' '--enable-plain' '--enable-login' '--disable-krb4' '--with-saslauthd=3D/var/run/saslauthd' '--libdir=3D/usr/lib/sasl2' '--with-plugindir=3D/usr/lib/sasl2' '--with-pam=3D/lib/security' --cache-file=3D.././config.cache --srcdir=3D. >configure: WARNING: Disabling GSSAPI - no include files found >checking for pam_start in -lpam... (cached) no > > >I do have pam installed.. I have recompiled pam and installed latest libraries. > > Can someone please give me a hint ? From owner-ietf-sasl Sat Dec 6 20:31:35 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB74VZib022099 for ; Sat, 6 Dec 2003 20:31:35 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB74VZNh022098 for ietf-sasl-bks; Sat, 6 Dec 2003 20:31:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB74VPib022089 for ; Sat, 6 Dec 2003 20:31:32 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.10/8.12.10) with ESMTP id hB74V6AU007454 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 7 Dec 2003 05:31:11 +0100 To: Jeffrey Hutzelman Cc: Sam Hartman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> <58040000.1070494633@minbar.fac.cs.cmu.edu> From: Simon Josefsson X-Payment: hashcash 1.2 0:031207:jhutz@cmu.edu:3158a3f29a2de7ad X-Hashcash: 0:031207:jhutz@cmu.edu:3158a3f29a2de7ad X-Payment: hashcash 1.2 0:031207:hartmans@mit.edu:9a7fb563e1dda382 X-Hashcash: 0:031207:hartmans@mit.edu:9a7fb563e1dda382 X-Payment: hashcash 1.2 0:031207:ietf-sasl@imc.org:22c45d20771641d2 X-Hashcash: 0:031207:ietf-sasl@imc.org:22c45d20771641d2 Date: Sun, 07 Dec 2003 05:30:47 +0100 In-Reply-To: <58040000.1070494633@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Wed, 03 Dec 2003 18:37:13 -0500") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman writes: > On Wednesday, December 03, 2003 19:56:03 +0100 Simon Josefsson > wrote: > >> I don't see a conflict with this and the text I proposed, but I'm not >> sure if you argue for or against the text. In fact, the problem of >> forward compatible databases was the motivation for my text. The text >> would help if SASLPrepX(SASLPrep(string)) != SASLPrepX(string) where >> SASLPrepX is any future revision of SASLPrep. > > Yeah; that's supposed to be a guarantee. Part of this is spelled out > in RFC2454, at the end of section 3 and in section 7.1: > > Authors of profiles of this document need to consider the effects of > changing the mapping of any currently-assigned character when > updating their profiles. Adding a new mapping for a currently- > assigned character, or changing an existing mapping, could cause a > variance between the behavior of systems that have been updated and > systems that have not been updated. This is not much of a guarantee. To me, the wording suggest that stringprep profiles actually can be backwards incompatible, if the designers feel the benefits outweigh the costs that are mentioned. > A subsequent version of a profile that references a newer version of > a repertoire with new code points will inherently have some code > points move from category U to either D, MN, or AO. For backwards > compatibility, a subsequent version of a profile MUST NOT move code > points from any other category. That is, current AO, MN, or D code > points MUST NOT ever change to a different category. This is good text, and I thought it would take of this problem. However, it doesn't appear to be that simple, because it continue to say: Applications creating queries MUST treat U code points as if they were AO when preparing the query to be entered in the process described by a profile of stringprep. Those applications MAY optionally have a preprocessor that provide stricter checks: treating unassigned code points in the input as errors, or warning the user about the fact that the code point is unassigned in the version of a profile that the software is based on; such a choice is a local matter for the software. So the result is that if the profile is used with AllowUnassigned set to true, the computed strings are not necessarily forwards compatible. Furthermore, one of the three ways forward presented in draft-faltstrom-unicode-synchronisation-00, to support new Unicode versions, include breaking backwards compatibility in stringprep profiles. To summarize, I don't believe the SASLPrep2(SASLPrep1(string)) == SASLPrep2(string) guarantee hold universally, nor follow from the core document. This problem can be solved by adding a discussion in the SASLPrep document that contain some guarantee that will hold for future versions of the SASLPrep profile. Perhaps even explicitly mention which path in draft-faltstrom-unicode-synchronisation-00 SASLPrep will follow. Alternatively, you could recommend applications to store the unprepared original passwords, which will be safe regardless of what SASLPrep will behave in the future. I prefer this approach, but judging from the responses to my proposed text for CRAM-MD5, perhaps there isn't consensus about that. Finally, each mechanism using SASLPrep should also say when and how AllowUnassigned is set. Thanks, Simon From owner-ietf-sasl Sun Dec 7 21:45:47 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB85jlib098527 for ; Sun, 7 Dec 2003 21:45:47 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB85jlXm098526 for ietf-sasl-bks; Sun, 7 Dec 2003 21:45:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mariner.pc.cs.cmu.edu (dsl093-061-085.pit1.dsl.speakeasy.net [66.93.61.85]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB85jfib098482 for ; Sun, 7 Dec 2003 21:45:43 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa04100; 8 Dec 2003 0:45 EST Date: Mon, 08 Dec 2003 00:44:59 -0500 From: Jeffrey Hutzelman To: Simon Josefsson cc: Jeffrey Hutzelman , Sam Hartman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt Message-ID: <3750000.1070862299@mariner.pc.cs.cmu.edu> In-Reply-To: References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> <58040000.1070494633@minbar.fac.cs.cmu.edu> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sunday, December 07, 2003 05:30:47 +0100 Simon Josefsson wrote: > Jeffrey Hutzelman writes: > >> On Wednesday, December 03, 2003 19:56:03 +0100 Simon Josefsson >> wrote: >> >>> I don't see a conflict with this and the text I proposed, but I'm not >>> sure if you argue for or against the text. In fact, the problem of >>> forward compatible databases was the motivation for my text. The text >>> would help if SASLPrepX(SASLPrep(string)) != SASLPrepX(string) where >>> SASLPrepX is any future revision of SASLPrep. >> >> Yeah; that's supposed to be a guarantee. Part of this is spelled out >> in RFC2454, at the end of section 3 and in section 7.1: >> >> Authors of profiles of this document need to consider the effects of >> changing the mapping of any currently-assigned character when >> updating their profiles. Adding a new mapping for a currently- >> assigned character, or changing an existing mapping, could cause a >> variance between the behavior of systems that have been updated and >> systems that have not been updated. > > This is not much of a guarantee. To me, the wording suggest that > stringprep profiles actually can be backwards incompatible, if the > designers feel the benefits outweigh the costs that are mentioned. Yes, I believe that's exactly what it says. It may not seem like much of a guarantee, but it's the best we can possibly have. Designers of future versions of a profile will always be able to break backward compatibility, no matter what we do -- no "requirement" we write now can be effective against an IETF concensus in the future. >> A subsequent version of a profile that references a newer version of >> a repertoire with new code points will inherently have some code >> points move from category U to either D, MN, or AO. For backwards >> compatibility, a subsequent version of a profile MUST NOT move code >> points from any other category. That is, current AO, MN, or D code >> points MUST NOT ever change to a different category. > > This is good text, and I thought it would take of this problem. > However, it doesn't appear to be that simple, because it continue to > say: > > Applications creating queries MUST treat U code points as if they > were AO when preparing the query to be entered in the process > described by a profile of stringprep. Those applications MAY > optionally have a preprocessor that provide stricter checks: treating > unassigned code points in the input as errors, or warning the user > about the fact that the code point is unassigned in the version of a > profile that the software is based on; such a choice is a local > matter for the software. > > So the result is that if the profile is used with AllowUnassigned set > to true, the computed strings are not necessarily forwards compatible. That is correct - if you apply stringprep with AllowUnassigned set to TRUE, there is no guarantee that two implementations will produce the same result given the same input. But that's OK for a query string that's going to be used "once", right now -- the worst thing that can happen is that it doesn't match when it "should". However, for a string that's going to be stored long-term, preparing it incorrectly now is fatal; it will then _NEVER_ match a correctly prepared string. If there are unassigned code points, then you can't know if you're preparing it correctly; the easiest solution to this problem is to raise an exception now, and refuse to store a string if you don't know how to prepare it correctly. That's what setting AllowUnassigned to FALSE does. So I'll go back to my original statement -- IF a server is going to prepare strings in advance (which it cannot avoid if it's going to precompute a partial MD5 context), then it MUST set AllowUnassigned to FALSE and reject strings which contain unassigned code points. > Furthermore, one of the three ways forward presented in > draft-faltstrom-unicode-synchronisation-00, to support new Unicode > versions, include breaking backwards compatibility in stringprep > profiles. I've not had a chance to read that document yet, so I can't comment on it. > To summarize, I don't believe the SASLPrep2(SASLPrep1(string)) == > SASLPrep2(string) guarantee hold universally, nor follow from the core > document. > > This problem can be solved by adding a discussion in the SASLPrep > document that contain some guarantee that will hold for future > versions of the SASLPrep profile. Perhaps even explicitly mention > which path in draft-faltstrom-unicode-synchronisation-00 SASLPrep will > follow. We can't make an effective guarantee against a future IETF concensus. But given the text in RFC2454, I do agree we need to address the issue, and express the intent that the mappings of code points not in class U will not change in future versions of the specification. > Alternatively, you could recommend applications to store the > unprepared original passwords, which will be safe regardless of what > SASLPrep will behave in the future. I prefer this approach, but > judging from the responses to my proposed text for CRAM-MD5, perhaps > there isn't consensus about that. I get the impression that people like the idea of storing a partial MD5 context, even though doing so doesn't offer much protection. If servers are going to do this, I think they should be REQUIRED to prepare with AllowUnassigned set FALSE. OTOH, if they're going to store passwords, I agree that storing unprepared passwords allows for the greatest chance of future interoperability. > Finally, each mechanism using SASLPrep should also say when and how > AllowUnassigned is set. Absolutely. -- Jeff From owner-ietf-sasl Sun Dec 14 09:02:10 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBEH2Aib075484 for ; Sun, 14 Dec 2003 09:02:10 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBEH2Aqf075483 for ietf-sasl-bks; Sun, 14 Dec 2003 09:02:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBEH1wib075470 for ; Sun, 14 Dec 2003 09:02:07 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust128.tnt110.lnd4.gbr.da.uu.net [62.188.174.128]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 14 Dec 2003 17:06:15 +0000 Message-ID: <3FDC8C1B.6070705@isode.com> Date: Sun, 14 Dec 2003 16:13:15 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: Moving to rfc2222bis last call References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >Sam Hartman writes: > > >>What are we still waiting on before the next last call of this >>document? >> >> > >I think this document needs another version before it is ready for last >call. Here is the unfinished business I'm aware of: > >------------------------------------------------------------------------ > >The 'suggested text about multiple SASL mechanisms' thread. > > I think this is done. >------------------------------------------------------------------------ > >Subject: Re: rfc2222bis: protocol profile? >From: Hallvard B Furuseth >Date: Mon, 10 Nov 2003 08:10:22 +0100 >Message-Id: >URL: http://www.imc.org/ietf-sasl/mail-archive/msg01304.html > >What belongs in the protocol profile? > > I will ignore this one, unless you have a specific suggestion/text. I am not sure I can give you a generic future proof advice. >------------------------------------------------------------------------ > >Subject: draft-ietf-sasl-rfc2222bis-02.txt section 4.2 >From: Tony Hansen >Date: Thu, 06 Nov 2003 12:02:22 -0500 >Message-ID: <3FAA7E9E.3080704@att.com> >URL: http://www.imc.org/ietf-sasl/mail-archive/msg01278.html > >Split section 4.2 (Authorization identities and proxy authentication). >It appears to be mixing two totally different discussions together in a >slightly confusing mess. > This is done. I had to merge my recent changes with the proposed text. >------------------------------------------------------------------------ > >The 'selects no security layer' thread. I've lost track of this one and >will have to reread it. But originally all I wanted was to clarify that >specific phrase: either to 'does not select a security layer' or >'selects that there shall be no security layer', or whatever else is >meant. That has not been done yet. > > I think I've addressed the particular issue by saying that mechanism that are incapable of negotiating a security layer always select "no layer". Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Mon Dec 15 01:56:11 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBF9uBib081505 for ; Mon, 15 Dec 2003 01:56:11 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBF9uBIe081504 for ietf-sasl-bks; Mon, 15 Dec 2003 01:56:11 -0800 (PST) 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.10/8.12.8) with ESMTP id hBF9u4ib081451 for ; Mon, 15 Dec 2003 01:56:05 -0800 (PST) (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 1AVpSL-0005vd-Lj; Mon, 15 Dec 2003 10:56:01 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.14) id 1AVpSK-0000iZ-H1; Mon, 15 Dec 2003 10:56:00 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AVpSK-0006nn-00; Mon, 15 Dec 2003 10:56:00 +0100 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Moving to rfc2222bis last call In-Reply-To: <3FDC8C1B.6070705@isode.com> References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> <3FDC8C1B.6070705@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 15 Dec 2003 10:56:00 +0100 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=-4.9, required 12, BAYES_00 -4.90) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >> Subject: Re: rfc2222bis: protocol profile? >> From: Hallvard B Furuseth >> Date: Mon, 10 Nov 2003 08:10:22 +0100 >> Message-Id: >> URL: http://www.imc.org/ietf-sasl/mail-archive/msg01304.html >> >> What belongs in the protocol profile? > > I will ignore this one, unless you have a specific suggestion/text. > I am not sure I can give you a generic future proof advice. I can't offer any suggestions because I don't know what belongs there. I think what I'm really missing is a description of the purpose of the protocol profile. What will it be used for? What is it _not_ intended to be used for? Knowing that, the reader (and I) can judge for himself what should go in it, besides the mandatory items. >> The 'selects no security layer' thread. I've lost track of this one and >> will have to reread it. But originally all I wanted was to clarify that >> specific phrase: either to 'does not select a security layer' or >> 'selects that there shall be no security layer', or whatever else is >> meant. That has not been done yet. > > I think I've addressed the particular issue by saying that mechanism > that are incapable of negotiating a security layer always select "no layer". OK, if the quotes are in place, or otherwise the new wording can't be interpreted as "doesn't select a (new) layer". -- Hallvard From owner-ietf-sasl Mon Dec 15 03:03:28 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFB3Rib089148 for ; Mon, 15 Dec 2003 03:03:27 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFB3RoW089147 for ietf-sasl-bks; Mon, 15 Dec 2003 03:03:27 -0800 (PST) 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.10/8.12.8) with ESMTP id hBFB3Pib089112 for ; Mon, 15 Dec 2003 03:03:25 -0800 (PST) (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 1AVqVW-0000MH-RY for ietf-sasl@imc.org; Mon, 15 Dec 2003 12:03:22 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AVqVN-0006ez-Kf for ietf-sasl@imc.org; Mon, 15 Dec 2003 12:03:13 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AVqVN-0006y4-00 for ietf-sasl@imc.org; Mon, 15 Dec 2003 12:03:13 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: ANONYMOUS In-Reply-To: References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 15 Dec 2003 12:03:13 +0100 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=-4.9, required 12, BAYES_00 -4.90) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [anon] section 4 (Security Considerations) says: > The ANONYMOUS mechanism grants access to information by anyone. For > this reason it should be disabled by default so the administrator can > make an explicit decision to enable it. I disagree. I see no reason to disable ANONYMOUS as long as ANONYMOUS 'authentication' is treated as equivalent to no authentication rather than e.g. as authentication with a password. What is needed is a securicy consideration that ANONYMOUS must not (or MUST NOT?) be enabled unless it is treated specially in this respect. If anon is treated as no auth, some other security considerations disappear too, since they are no different from if the user did not authenticate: > If the anonymous user has any write privileges, a denial of service > attack is possible by filling up all available space. This can be > prevented by disabling all write access by anonymous users. > If anonymous users have read and write access to the same area, the > server can be used as a communication mechanism to anonymously > exchange information. (...) > If the anonymous user can run many expensive operations (e.g., an IMAP > SEARCH BODY command), this could enable a denial of service attack. > While servers may impose a limit on the number of anonymous users, it > is noted that such limits enable denial of service attacks and should > be used with caution. Also, > Anonymous connections are susceptible to man in the middle attacks > which view or alter the data transferred. Clients and servers are > encouraged to support external integrity and encryption mechanisms. It's not that the connection is anonymous which makes it suspectible, but that [anon] provides no SASL security layer. Also, in an earlier thread, I wrote: >Alexey Melnikov writes: >>Kurt D. Zeilenga wrote: >>>At 04:45 PM 11/5/2003, Hallvard B Furuseth wrote: >>> >>>> Looking over the various SASL drafts, I miss one piece of functionality: >>>> To authenticate anonymously, removing any SASL layer, but still >>>> providing an unauthenticated ID (e.g. for logging purposes). >>>> >> How is this different from ANONYMOUS (except for @ sign requirement). > > That's the difference. If there is nothing special about the '@' > character in the underlying auth IDs, then the exclusion of names with > '@' in them is unnatural. Though one could of course introduce a > private hack like using \ for a quote character and type @ as \40, or > something. That reminds me: Would it be appropriate to put something like this in [anon]? A protocol using the ANONYMOUS mechanism may impose additional syntax on , e.g. it may say that the NUL, '@' and '\' characters are to be encoded as '\00', '\40' and '\5C' respectively in - thus allowing such tokens to encode all characters. -- Hallvard From owner-ietf-sasl Mon Dec 15 10:22:00 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFIM0ib010396 for ; Mon, 15 Dec 2003 10:22:00 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFIM07V010395 for ietf-sasl-bks; Mon, 15 Dec 2003 10:22:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (HOTASS-6.MIT.EDU [18.101.1.48]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFILxib010383 for ; Mon, 15 Dec 2003 10:21:59 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 66ED41515F2; Mon, 15 Dec 2003 13:22:00 -0500 (EST) To: Hallvard B Furuseth Cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: Moving to rfc2222bis last call References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> <3FDC8C1B.6070705@isode.com> From: Sam Hartman Date: Mon, 15 Dec 2003 13:22:00 -0500 In-Reply-To: (Hallvard B. Furuseth's message of "Mon, 15 Dec 2003 10:56:00 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Hallvard" == Hallvard B Furuseth writes: Hallvard> I can't offer any suggestions because I don't know what Hallvard> belongs there. I think what I'm really missing is a Hallvard> description of the purpose of the protocol profile. Hallvard> What will it be used for? What is it _not_ intended to Hallvard> be used for? Knowing that, the reader (and I) can judge Hallvard> for himself what should go in it, besides the mandatory Hallvard> items. Does anyone else feel this issue requires additional clarification? From owner-ietf-sasl Mon Dec 15 10:32:18 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFIWIib010978 for ; Mon, 15 Dec 2003 10:32:18 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFIWIIF010977 for ietf-sasl-bks; Mon, 15 Dec 2003 10:32:18 -0800 (PST) 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.10/8.12.8) with ESMTP id hBFIWHib010964 for ; Mon, 15 Dec 2003 10:32:17 -0800 (PST) (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 1AVxVv-0007c3-No; Mon, 15 Dec 2003 19:32:15 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.14) id 1AVxSW-0000us-NA; Mon, 15 Dec 2003 19:28:44 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AVxSW-0000H5-00; Mon, 15 Dec 2003 19:28:44 +0100 From: Hallvard B Furuseth Message-Id: To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: ANONYMOUS In-Reply-To: References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 15 Dec 2003 19:28:44 +0100 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=-4.9, required 12, BAYES_00 -4.90) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: >>>>>> "Hallvard" == Hallvard B Furuseth writes: > > Hallvard> What is needed is a > Hallvard> securicy consideration that ANONYMOUS must not (or MUST > Hallvard> NOT?) be enabled unless it is treated specially in this > Hallvard> respect. > > I think a SHOULD is sufficient. (...) OK. BTW, would it help to specify that ANONYMOUS gives the specified authentication ID, but a null authorization ID? -- Hallvard From owner-ietf-sasl Mon Dec 15 10:20:10 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFIKAib010243 for ; Mon, 15 Dec 2003 10:20:10 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFIKA4R010241 for ietf-sasl-bks; Mon, 15 Dec 2003 10:20:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (HOTASS-6.MIT.EDU [18.101.1.48]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFIK8ib010231 for ; Mon, 15 Dec 2003 10:20:09 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 20DA71515F2; Mon, 15 Dec 2003 13:20:08 -0500 (EST) To: Hallvard B Furuseth Cc: ietf-sasl@imc.org Subject: Re: ANONYMOUS References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> From: Sam Hartman Date: Mon, 15 Dec 2003 13:20:08 -0500 In-Reply-To: (Hallvard B. Furuseth's message of "Mon, 15 Dec 2003 12:03:13 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Hallvard" == Hallvard B Furuseth writes: Hallvard> [anon] section 4 (Security Considerations) says: >> The ANONYMOUS mechanism grants access to information by anyone. >> For this reason it should be disabled by default so the >> administrator can make an explicit decision to enable it. Hallvard> I disagree. I see no reason to disable ANONYMOUS as Hallvard> long as ANONYMOUS 'authentication' is treated as Hallvard> equivalent to no authentication rather than e.g. as Hallvard> authentication with a password. What is needed is a Hallvard> securicy consideration that ANONYMOUS must not (or MUST Hallvard> NOT?) be enabled unless it is treated specially in this Hallvard> respect. I think a SHOULD is sufficient. If your application/environment has well defined no authentication semantics, then you have a justification for violating the SHOULD. Write it up in your docs/specifications, explain what behavior you have and why you chose it and go on with life. From owner-ietf-sasl Mon Dec 15 11:13:15 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFJDFib013035 for ; Mon, 15 Dec 2003 11:13:15 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFJDFGF013034 for ietf-sasl-bks; Mon, 15 Dec 2003 11:13:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (HOTASS-6.MIT.EDU [18.101.1.48]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFJDEib013029 for ; Mon, 15 Dec 2003 11:13:14 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 93FDD1515F2; Mon, 15 Dec 2003 14:13:11 -0500 (EST) To: "Kurt D. Zeilenga" Cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: ANONYMOUS References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> <6.0.0.22.0.20031215110302.042ab1d0@127.0.0.1> From: Sam Hartman Date: Mon, 15 Dec 2003 14:13:11 -0500 In-Reply-To: <6.0.0.22.0.20031215110302.042ab1d0@127.0.0.1> (Kurt D. Zeilenga's message of "Mon, 15 Dec 2003 11:09:01 -0800") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> As this is a security consideration, not an implementation Kurt> imperative nor applicability statement, I believe 'should' Kurt> is more appropriate than 'SHOULD'. I don't much care but how is this particular security consideration not an implementation imperative justified for security reasons? From owner-ietf-sasl Mon Dec 15 11:09:28 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFJ9Sib012897 for ; Mon, 15 Dec 2003 11:09:28 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFJ9SxO012896 for ietf-sasl-bks; Mon, 15 Dec 2003 11:09:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFJ9Rib012891 for ; Mon, 15 Dec 2003 11:09:27 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.9) with ESMTP id hBFJ9Sa9061308; Mon, 15 Dec 2003 19:09:29 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031215110302.042ab1d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 15 Dec 2003 11:09:01 -0800 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: ANONYMOUS Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:20 AM 12/15/2003, Sam Hartman wrote: >>>>>> "Hallvard" == Hallvard B Furuseth writes: > > Hallvard> [anon] section 4 (Security Considerations) says: > > >> The ANONYMOUS mechanism grants access to information by anyone. > >> For this reason it should be disabled by default so the > >> administrator can make an explicit decision to enable it. > > Hallvard> I disagree. I see no reason to disable ANONYMOUS as > Hallvard> long as ANONYMOUS 'authentication' is treated as > Hallvard> equivalent to no authentication rather than e.g. as > Hallvard> authentication with a password. What is needed is a > Hallvard> securicy consideration that ANONYMOUS must not (or MUST > Hallvard> NOT?) be enabled unless it is treated specially in this > Hallvard> respect. > >I think a SHOULD is sufficient. If your application/environment has >well defined no authentication semantics, then you have a >justification for violating the SHOULD. Write it up in your >docs/specifications, explain what behavior you have and why you chose >it and go on with life. As this is a security consideration, not an implementation imperative nor applicability statement, I believe 'should' is more appropriate than 'SHOULD'. But same basic logic applies here. Implementors should consider the implications before enabling ANONYMOUS by default. From owner-ietf-sasl Mon Dec 15 11:41:18 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFJfIib014180 for ; Mon, 15 Dec 2003 11:41:18 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFJfIo0014179 for ietf-sasl-bks; Mon, 15 Dec 2003 11:41:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFJfHib014173 for ; Mon, 15 Dec 2003 11:41:17 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from CYRUS-TEST.andrew.cmu.edu (CYRUS-TEST.andrew.cmu.edu [128.2.10.171]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hBFJfIk5004012 for ; Mon, 15 Dec 2003 14:41:18 -0500 Date: Mon, 15 Dec 2003 14:41:17 -0500 (EST) From: Rob Siemborski To: ietf-sasl@imc.org Subject: Re: Moving to rfc2222bis last call In-Reply-To: <20031201174409.A27F91515F2@konishi-polis.mit.edu> Message-ID: References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 1 Dec 2003, Sam Hartman wrote: > What are we still waiting on before the next last call of this > document? I just noticed that the EXTERNAL mechanism doesn't have any limits on how big the client response can be. Are servers expected to handle responses of arbitrary length here, or can they get away with saying "we don't support authorization identifiers longer than x"? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Mon Dec 15 12:00:51 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFK0pib015210 for ; Mon, 15 Dec 2003 12:00:51 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFK0pHX015209 for ietf-sasl-bks; Mon, 15 Dec 2003 12:00:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFK0oib015203 for ; Mon, 15 Dec 2003 12:00:50 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.9) with ESMTP id hBFK0pa9061824; Mon, 15 Dec 2003 20:00:51 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031215114026.041860c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 15 Dec 2003 12:00:24 -0800 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: ANONYMOUS Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> <6.0.0.22.0.20031215110302.042ab1d0@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:13 AM 12/15/2003, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > > Kurt> As this is a security consideration, not an implementation > Kurt> imperative nor applicability statement, I believe 'should' > Kurt> is more appropriate than 'SHOULD'. > >I don't much care but how is this particular security consideration >not an implementation imperative justified for security reasons? My primary concern is not to give this 'should' special attention over the many other 'should' statements in the Security Considerations section AND not to litter the Security Considerations section with lots of SHOULDs. SHOULDs should be used sparingly. I think the current wording is fine. The section discusses security considerations. If, however, people think that we need to state specific implementation imperatives in this area, I suggest those be added to Section 1 and the Security Considerations section be left to just discussing considerations. Kurt From owner-ietf-sasl Mon Dec 15 12:12:36 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFKCaib015770 for ; Mon, 15 Dec 2003 12:12:36 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFKCa2Q015769 for ietf-sasl-bks; Mon, 15 Dec 2003 12:12:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFKCZib015764 for ; Mon, 15 Dec 2003 12:12:35 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.9) with ESMTP id hBFKCYa9061914; Mon, 15 Dec 2003 20:12:35 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031215120505.0419ac40@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 15 Dec 2003 12:12:08 -0800 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: Moving to rfc2222bis last call Cc: ietf-sasl@imc.org In-Reply-To: References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:41 AM 12/15/2003, Rob Siemborski wrote: >On Mon, 1 Dec 2003, Sam Hartman wrote: > >> What are we still waiting on before the next last call of this >> document? > >I just noticed that the EXTERNAL mechanism doesn't have any limits on how >big the client response can be. > >Are servers expected to handle responses of arbitrary length here, I assume they should be able to 'handle' (not choke) authzid of any length but can refuse to accept any authzid for any reason (including it just being unreasonably long). >or can >they get away with saying "we don't support authorization identifiers >longer than x"? They just generally should fail the exchange if the asserted authzid is too long (whatever that means to them). Of course, if the server believes the client to be rouge, it can (and likely should) just drop the protocol steam. I do not think we should impose any artificial limit here as reasonable lengths. Where absolutely needed, they should be stated in application-level profiles (as they own the form of the authzid). Kurt From owner-ietf-sasl Tue Dec 23 12:35:46 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNKZjib053926 for ; Tue, 23 Dec 2003 12:35:45 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBNKZjkP053925 for ietf-sasl-bks; Tue, 23 Dec 2003 12:35:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNKZiib053910 for ; Tue, 23 Dec 2003 12:35:45 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08146; Tue, 23 Dec 2003 15:35:44 -0500 (EST) Message-Id: <200312232035.PAA08146@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-04.txt Date: Tue, 23 Dec 2003 15:35:43 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-04.txt Pages : 11 Date : 2003-12-23 SASL provides a method for adding authentication support with an optional security layer to connection-based protocols. It also describes a structure for authentication mechanisms. The result is an abstraction layer between protocols and authentication mechanisms such that any SASL-compatible authentication mechanism can be used with any SASL-compatible protocol. This document describes how a SASL authentication mechanism is structured, how a protocol adds support for SASL, defines the protocol for carrying a security layer over a connection, and defines the EXTERNAL SASL authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2222bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-23153249.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-23153249.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Mon Dec 29 12:48:50 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTKmoib010713 for ; Mon, 29 Dec 2003 12:48:50 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBTKmoPv010712 for ietf-sasl-bks; Mon, 29 Dec 2003 12:48:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTKmkib010702 for ; Mon, 29 Dec 2003 12:48:48 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hBTKmKl4008794; Mon, 29 Dec 2003 15:48:20 -0500 Date: Mon, 29 Dec 2003 15:48:20 -0500 (EST) From: Rob Siemborski To: Internet-Drafts@ietf.org cc: ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-04.txt In-Reply-To: <200312232035.PAA08146@ietf.org> Message-ID: References: <200312232035.PAA08146@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: On Tue, 23 Dec 2003 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. > > Title : Simple Authentication and Security Layer (SASL) Nit: Document states that it will be a draft standard, is this still the case or is the stringprep stuff forcing us to recycle at proposed? I've sent additional editorial isses to Alexey, but nothing that should hold up the document. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Mon Dec 29 13:35:01 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTLZ1ib013905 for ; Mon, 29 Dec 2003 13:35:01 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBTLZ12T013904 for ietf-sasl-bks; Mon, 29 Dec 2003 13:35:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTLYwib013893 for ; Mon, 29 Dec 2003 13:35:00 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.9) with ESMTP id hBTLYwa9075518; Mon, 29 Dec 2003 21:34:58 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031229133042.02716f20@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 29 Dec 2003 13:34:47 -0800 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-04.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200312232035.PAA08146@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:48 PM 12/29/2003, Rob Siemborski wrote: >On Tue, 23 Dec 2003 Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. >> >> Title : Simple Authentication and Security Layer (SASL) > >Nit: Document states that it will be a draft standard, is this still the >case or is the stringprep stuff forcing us to recycle at proposed? We'll be recycling at Proposed. >I've sent additional editorial isses to Alexey, but nothing that should >hold up the document. Thanks, Kurt From owner-ietf-sasl Mon Dec 1 09:44:13 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1HiDib098345 for ; Mon, 1 Dec 2003 09:44:13 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB1HiD2H098344 for ietf-sasl-bks; Mon, 1 Dec 2003 09:44:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-ONE-O-NINE.MIT.EDU [18.187.5.109]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1HiAib098336 for ; Mon, 1 Dec 2003 09:44:12 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id A27F91515F2; Mon, 1 Dec 2003 12:44:09 -0500 (EST) To: ietf-sasl@imc.org Subject: Moving to rfc2222bis last call Message-Id: <20031201174409.A27F91515F2@konishi-polis.mit.edu> Date: Mon, 1 Dec 2003 12:44:09 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: What are we still waiting on before the next last call of this document? From owner-ietf-sasl Mon Dec 1 12:30:59 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1KUxib006007 for ; Mon, 1 Dec 2003 12:30:59 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB1KUxD8006006 for ietf-sasl-bks; Mon, 1 Dec 2003 12:30:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1KUwib005999 for ; Mon, 1 Dec 2003 12:30:58 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27449; Mon, 1 Dec 2003 15:30:46 -0500 (EST) Message-Id: <200312012030.PAA27449@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-crammd5-01.txt Date: Mon, 01 Dec 2003 15:30:46 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The CRAM-MD5 SASL Mechanism Author(s) : L. Nerenberg Filename : draft-ietf-sasl-crammd5-01.txt Pages : 7 Date : 2003-12-1 This document defines a simple challenge-response authentication mechanism, using a keyed-hash digest, for use with the Simple Authentication and Security Layer (SASL) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-crammd5-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-crammd5-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-1152419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-crammd5-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-crammd5-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-1152419.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Mon Dec 1 13:48:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1Lmbib008660 for ; Mon, 1 Dec 2003 13:48:37 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB1LmbYS008659 for ietf-sasl-bks; Mon, 1 Dec 2003 13:48:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1LmZib008654 for ; Mon, 1 Dec 2003 13:48:35 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hB1LmZlg001254; Mon, 1 Dec 2003 21:48:35 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031201131838.0426ae78@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 01 Dec 2003 13:47:40 -0800 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms Cc: Rob Siemborski , Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 07:16 PM 11/14/2003, Sam Hartman wrote: >One thing we need to keep in mind is that over time, we get a better >idea of what best practices for using SASL are. My operational experiences with LDAP show that making available a list of mechanisms post authentication isn't the "best" practice for preventing MITM downgrade attacks. I think the "best" practice is for the client and server to have policy which states what the levels of service are or are not acceptable (and when). A simple mechanism can just dictate minimum levels and refuse when not met. A more complex mechanism could have two levels, minimum and recommend, where less than recommended but higher than minimum required user authorization. I think the list mechanism approach in LDAP is a bit problematic. First, SASL (or other) security layers may not have been established making the information subject to MITM attack. Second, LDAP allows the list of mechanisms to change based upon current availability (to this client). It is possible that a stronger mechanism is, for legitimate reasons, no longer available. It is not possible for the client to deduce why a change in the listing was made. A more workable approach would be to recommend the server provide a list of mechanisms which WERE available to the client when it authenticated to the server. Lastly, the list doesn't prevent any similar MITM attacks (for example, downgrading of the cipher suites used by a listed mechanism). I also note that I have yet to find a client which actually uses the list of available mechanisms to detect MITM attacks. Clients which do attempt to detect such attacks tend to use a policy based mechanism. In short, I don't think we have enough good operational experience to add these imperatives to the technical specification. Kurt From owner-ietf-sasl Mon Dec 1 14:06:44 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1M6iib009754 for ; Mon, 1 Dec 2003 14:06:44 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB1M6i7b009753 for ietf-sasl-bks; Mon, 1 Dec 2003 14:06:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1M6hib009747 for ; Mon, 1 Dec 2003 14:06:43 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 1CDE71515F2; Mon, 1 Dec 2003 17:06:44 -0500 (EST) To: "Kurt D. Zeilenga" Cc: Rob Siemborski , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms References: <6.0.0.22.0.20031201131838.0426ae78@127.0.0.1> From: Sam Hartman Date: Mon, 01 Dec 2003 17:06:44 -0500 In-Reply-To: <6.0.0.22.0.20031201131838.0426ae78@127.0.0.1> (Kurt D. Zeilenga's message of "Mon, 01 Dec 2003 13:47:40 -0800") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> At 07:16 PM 11/14/2003, Sam Hartman wrote: >> One thing we need to keep in mind is that over time, we get a >> better idea of what best practices for using SASL are. Kurt> My operational experiences with LDAP show that making Kurt> available a list of mechanisms post authentication isn't the Kurt> "best" practice for preventing MITM downgrade attacks. Kurt> I think the "best" practice is for the client and server to Kurt> have policy which states what the levels of service are or Kurt> are not acceptable (and when). A simple mechanism can just Kurt> dictate minimum levels and refuse when not met. A more Kurt> complex mechanism could have two levels, minimum and Kurt> recommend, where less than recommended but higher than Kurt> minimum required user authorization. We all agree this is sufficient. However I believe that IETF experience with other security protocols strongly favors having a way to detect downgrades when possible. The problem is that in practice, people tend to establish fairly loose policies on their clients, so in situations where it is possible to detect the downgrade it is a good idea to do so. I agree there is not significant experience with this in the SASL community, but I believe there is sufficient experience in the SASL community to say that client policies do tend to be fairly lax and experience in the rest of the IETF to say that downgrade detection is desirable. I believe that is sufficient to provide advice for new protocols. From owner-ietf-sasl Mon Dec 1 14:40:04 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1Me4ib011085 for ; Mon, 1 Dec 2003 14:40:04 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB1Me4gL011084 for ietf-sasl-bks; Mon, 1 Dec 2003 14:40:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1Me0ib011076 for ; Mon, 1 Dec 2003 14:40:03 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.10/8.12.10) with ESMTP id hB1Me0rh017766 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 1 Dec 2003 23:40:01 +0100 To: ietf-sasl@imc.org Subject: draft-ietf-sasl-crammd5-01.txt From: Simon Josefsson X-Payment: hashcash 1.2 0:031201:ietf-sasl@imc.org:0b9356fad30d5eac X-Hashcash: 0:031201:ietf-sasl@imc.org:0b9356fad30d5eac Date: Mon, 01 Dec 2003 23:39:51 +0100 Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, I have read the document. Some comments: ,---- | The client MUST prepare the user name and shared secret strings | using the [SASLPrep] profile of the [StringPrep] algorithm. The | resulting values MUST be encoded as UTF-8 [UTF8]. `---- I suggest adding: The server MUST prepare the shared secret string using the [SASLPrep] profile of the [StringPrep] algorithm. The resulting value MUST be encoded as UTF-8 [UTF8]. The server may store the prepared string instead of, or as well as, the unprepared string, so that it does not have to prepare it every time it is needed for computation. However, if the original, unprepared string, is not stored, it may render the computed secret to be incompatible with a future revisions of SASLPrep that support currently unassigned code points (compare section 7 of [StringPrep]). It is therefor recommended to store the unprepared string in the database. Also, the example section is incorrect. Suggested new version: S: * OK [CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED AUTH=CRAM-MD5] C: A0001 AUTHENTICATE CRAM-MD5 S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UuZXhhbXBsZS5uZXQ+ C: am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3 S: A0001 OK CRAM-MD5 authentication successful In this example, the shared secret is the string tanstaaftanstaaf Hence, the Keyed MD5 digest is produced by calculating MD5((tanstaaftanstaaf XOR opad), MD5((tanstaaftanstaaf XOR ipad), <1896.697170952@postoffice.example.net>)) where ipad and opad are as defined in [KEYED-MD5] and the string shown in the challenge is the base64 encoding of <1896.697170952@postoffice.example.net>. The shared secret is null-padded to a length of 64 bytes. If the shared secret is longer than 64 bytes, the MD5 digest of the shared secret is used as a 16 byte input to the keyed MD5 calculation. This produces a digest value (in hexadecimal) of 3dbc88f0624776a737b39093f6eb6427 The user name is then prepended to it, forming joe 3dbc88f0624776a737b39093f6eb6427 Which is then base64 encoded to meet the requirements of the IMAP4 AUTHENTICATE command (or the similar POP3 AUTH command), yielding am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3 Perhaps it would be useful to add an example for non-ASCII strings too, using or similar to indicate non-ASCII characters. Thanks, Simon From owner-ietf-sasl Mon Dec 1 15:05:32 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1N5Vib011780 for ; Mon, 1 Dec 2003 15:05:31 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB1N5ViH011779 for ietf-sasl-bks; Mon, 1 Dec 2003 15:05:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB1N5Uib011773 for ; Mon, 1 Dec 2003 15:05:30 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa09435; 1 Dec 2003 18:05 EST Date: Mon, 01 Dec 2003 18:05:02 -0500 From: Jeffrey Hutzelman To: Simon Josefsson , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt Message-ID: <1753870000.1070319902@minbar.fac.cs.cmu.edu> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Monday, December 01, 2003 23:39:51 +0100 Simon Josefsson wrote: > I suggest adding: > > The server MUST prepare the shared secret string using the > [SASLPrep] profile of the [StringPrep] algorithm. The resulting > value MUST be encoded as UTF-8 [UTF8]. The server may store the > prepared string instead of, or as well as, the unprepared > string, so that it does not have to prepare it every time it is > needed for computation. However, if the original, unprepared > string, is not stored, it may render the computed secret to be > incompatible with a future revisions of SASLPrep that support > currently unassigned code points (compare section 7 of > [StringPrep]). It is therefor recommended to store the > unprepared string in the database. The correct way to handle this situation is to require that if the server stores the prepared string (or maybe, even if not), the server prepare the string with AllowUnassigned set to FALSE, thereby prohibiting unassigned code points. If the server stores the prepared string, then it is properly a "storage string" and should not be permitted to contain unassigned code points. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From owner-ietf-sasl Tue Dec 2 01:21:04 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB29L4ib097014 for ; Tue, 2 Dec 2003 01:21:04 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB29L4uT097013 for ietf-sasl-bks; Tue, 2 Dec 2003 01:21:04 -0800 (PST) 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.10/8.12.8) with ESMTP id hB29L2ib096982 for ; Tue, 2 Dec 2003 01:21:03 -0800 (PST) (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 1AR6iJ-00047Q-QW; Tue, 02 Dec 2003 10:20:59 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AR6iF-0003uh-T0; Tue, 02 Dec 2003 10:20:55 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AR6iF-0007Sa-00; Tue, 2 Dec 2003 10:20:55 +0100 From: Hallvard B Furuseth Message-Id: To: hartmans@mit.edu (Sam Hartman) Cc: ietf-sasl@imc.org Subject: Re: Moving to rfc2222bis last call In-Reply-To: <20031201174409.A27F91515F2@konishi-polis.mit.edu> References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 2 Dec 2003 10:20:55 +0100 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=-4.9, required 12, BAYES_00 -4.90) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: > What are we still waiting on before the next last call of this > document? I think this document needs another version before it is ready for last call. Here is the unfinished business I'm aware of: ------------------------------------------------------------------------ The 'suggested text about multiple SASL mechanisms' thread. ------------------------------------------------------------------------ Subject: [Fwd: Keeping/dropping existing SASL security layer] From: Alexey Melnikov Date: Tue, 11 Nov 2003 20:35:01 +0000 Message-ID: <3FB147F5.3070902@isode.com> URL: http://www.imc.org/ietf-sasl/mail-archive/msg01312.html Alexey's attack when keeping an old security layer. He sent it to Rob and me before the list, and I replied that I still did not understand, with a list of where I got lost. ------------------------------------------------------------------------ Subject: Re: rfc2222bis: re-negotiating SASL security layer From: Hallvard B Furuseth Date: Tue, 11 Nov 2003 22:24:45 +0100 Message-Id: URL: http://www.imc.org/ietf-sasl/mail-archive/msg01313.html When can a security layer be removed? What I said in this message seems to reflect what Alexey said last, but I don't quite think that's what he meant... ------------------------------------------------------------------------ Subject: Re: rfc2222bis: protocol profile? From: Hallvard B Furuseth Date: Mon, 10 Nov 2003 08:10:22 +0100 Message-Id: URL: http://www.imc.org/ietf-sasl/mail-archive/msg01304.html What belongs in the protocol profile? ------------------------------------------------------------------------ Subject: draft-ietf-sasl-rfc2222bis-02.txt section 4.2 From: Tony Hansen Date: Thu, 06 Nov 2003 12:02:22 -0500 Message-ID: <3FAA7E9E.3080704@att.com> URL: http://www.imc.org/ietf-sasl/mail-archive/msg01278.html Split section 4.2 (Authorization identities and proxy authentication). It appears to be mixing two totally different discussions together in a slightly confusing mess. ------------------------------------------------------------------------ The 'selects no security layer' thread. I've lost track of this one and will have to reread it. But originally all I wanted was to clarify that specific phrase: either to 'does not select a security layer' or 'selects that there shall be no security layer', or whatever else is meant. That has not been done yet. ------------------------------------------------------------------------ -- Hallvard From owner-ietf-sasl Tue Dec 2 11:31:23 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2JVMib036415 for ; Tue, 2 Dec 2003 11:31:23 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB2JVMRH036414 for ietf-sasl-bks; Tue, 2 Dec 2003 11:31:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2JVJib036406 for ; Tue, 2 Dec 2003 11:31:19 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 86F161515F2; Tue, 2 Dec 2003 14:31:20 -0500 (EST) To: Jeffrey Hutzelman Cc: Simon Josefsson , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Tue, 02 Dec 2003 14:31:20 -0500 In-Reply-To: <1753870000.1070319902@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Mon, 01 Dec 2003 18:05:02 -0500") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> The correct way to handle this situation is to require Jeffrey> that if the server stores the prepared string (or maybe, Jeffrey> even if not), the server prepare the string with Jeffrey> AllowUnassigned set to FALSE, thereby prohibiting Jeffrey> unassigned code points. If the server stores the Jeffrey> prepared string, then it is properly a "storage string" Jeffrey> and should not be permitted to contain unassigned code Jeffrey> points. I agree. I believe cram-md5 should always treat the secret as a storage string when it is updating its database. From owner-ietf-sasl Tue Dec 2 16:21:20 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB30LKib061041 for ; Tue, 2 Dec 2003 16:21:20 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB30LKv8061040 for ietf-sasl-bks; Tue, 2 Dec 2003 16:21:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB30LIib061034 for ; Tue, 2 Dec 2003 16:21:19 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.10/8.12.10) with ESMTP id hB30LGrh016695 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 3 Dec 2003 01:21:16 +0100 To: Sam Hartman Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Simon Josefsson X-Payment: hashcash 1.2 0:031203:hartmans@mit.edu:c80f5a86ea7835da X-Hashcash: 0:031203:hartmans@mit.edu:c80f5a86ea7835da X-Payment: hashcash 1.2 0:031203:jhutz@cmu.edu:16e069d1593831ca X-Hashcash: 0:031203:jhutz@cmu.edu:16e069d1593831ca X-Payment: hashcash 1.2 0:031203:ietf-sasl@imc.org:eb01571a02ef3851 X-Hashcash: 0:031203:ietf-sasl@imc.org:eb01571a02ef3851 Date: Wed, 03 Dec 2003 01:21:04 +0100 In-Reply-To: (Sam Hartman's message of "Tue, 02 Dec 2003 14:31:20 -0500") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: >>>>>> "Jeffrey" == Jeffrey Hutzelman writes: > > Jeffrey> The correct way to handle this situation is to require > Jeffrey> that if the server stores the prepared string (or maybe, > Jeffrey> even if not), the server prepare the string with > Jeffrey> AllowUnassigned set to FALSE, thereby prohibiting > Jeffrey> unassigned code points. If the server stores the > Jeffrey> prepared string, then it is properly a "storage string" > Jeffrey> and should not be permitted to contain unassigned code > Jeffrey> points. > > > I agree. I believe cram-md5 should always treat the secret as a > storage string when it is updating its database. I'm having trouble understanding what these statements imply for the protocol. Perhaps my trouble is because the discussion is now focused on the database, and not on the protocol. Do you mean that servers will be _required_ to use passwords prepared with AllowUnassigned false in the HMAC-MD5 computation? Regardless of whether the prepared string is ever stored in a database? If the answer is yes, I don't agree, because that would make CRAM-MD5 reject passwords containing characters introduced by Unicode 4.0.0. Regards, Simon PS. Forward compatibility issues with StringPrep profiles are discussed in the recent draft-faltstrom-unicode-synchronisation-00. From owner-ietf-sasl Tue Dec 2 20:10:48 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB34Amib068338 for ; Tue, 2 Dec 2003 20:10:48 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB34AmZP068337 for ietf-sasl-bks; Tue, 2 Dec 2003 20:10:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB34Akib068332 for ; Tue, 2 Dec 2003 20:10:46 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hB34Aelg023477; Wed, 3 Dec 2003 04:10:41 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031202193544.02757990@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 02 Dec 2003 20:09:44 -0800 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-sasl-crammd5-01.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 04:21 PM 12/2/2003, Simon Josefsson wrote: > Regardless of whether the prepared string is ever stored in a > database? First, I think "in a database" is a unnecessary qualification. All that matters is that it is a "stored" string per stringprep. In each of the password-based mechanisms (PLAIN, CRAM-MD5, DIGEST-MD5, etc.), the user provided string is clear a "query" string and the string which it is compared against (directly or indirectly) is a "stored" string (regardless of whether the server stores it locally or in some external systems). > Perhaps my trouble is because the discussion is now focused > on the database, and not on the protocol. I do think that it should be considered an implementation detail whether the server applies SASLprep with unassigned disallowed before or after use storage. What matters to the protocol/algorithm is the server apply the SASLprep with disallowed before comparison to the "stored" string. Generally, doing it before storage is more appropriate. However, there is no harm (and there may be advantage in some instances (e.g., external password stores)) of doing it after fetching it from storage (BUT before comparison). So, maybe we're agreeing... >If the answer is yes, I don't agree, because that would make CRAM-MD5 >reject passwords containing characters introduced by Unicode 4.0.0. As intended! Until stringprep is updated to detail how these newly assigned code points are to be handled, we need to exclude them from appearing in the "stored" password string. Kurt From owner-ietf-sasl Wed Dec 3 09:21:30 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3HLUib070096 for ; Wed, 3 Dec 2003 09:21:30 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3HLUGW070095 for ietf-sasl-bks; Wed, 3 Dec 2003 09:21:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-NINETEEN.MIT.EDU [18.187.5.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3HLSib070090 for ; Wed, 3 Dec 2003 09:21:28 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id AF9971515F2; Wed, 3 Dec 2003 12:21:28 -0500 (EST) To: Simon Josefsson Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Wed, 03 Dec 2003 12:21:28 -0500 In-Reply-To: (Simon Josefsson's message of "Wed, 03 Dec 2003 01:21:04 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Simon" == Simon Josefsson writes: Simon> I'm having trouble understanding what these statements Simon> imply for the protocol. Perhaps my trouble is because the Simon> discussion is now focused on the database, and not on the Simon> protocol. Simon> Do you mean that servers will be _required_ to use Simon> passwords prepared with AllowUnassigned false in the Simon> HMAC-MD5 computation? I mean that this should be a requirement for interoperability in the long term. If you don't have this requirement, then you may run into cases where saslprep eventually maps out those characters in the future. Basically, if we require allowunassigned to be false, we guarantee future interoperability at the cost of refusing to allow people to use unassigned characters until saslprep is updated. From owner-ietf-sasl Wed Dec 3 11:08:54 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3J8sib076615 for ; Wed, 3 Dec 2003 11:08:54 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3J8sQ7076614 for ietf-sasl-bks; Wed, 3 Dec 2003 11:08:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-NINETEEN.MIT.EDU [18.187.5.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3J8rib076608 for ; Wed, 3 Dec 2003 11:08:53 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 8ABAC1515F2; Wed, 3 Dec 2003 14:08:52 -0500 (EST) To: ietf-sasl@imc.org Subject: Draft Minutes for SASL working group meeting From: Sam Hartman Date: Wed, 03 Dec 2003 14:08:52 -0500 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please comment; I'll submit at the end of the week or the proceedings deadline, whichever is sooner. From: Philip Guenther Minutes for IETF 58 SASL Working Group scribe: Philip Guenther guenther@sendmail.com chairs: Sam Hartman , Kurt Zeilenga agenda change: - add short discussion of private-use characters in saslprep status of drafts: - base-spec last call was not discussed in previous meeting, but it has been last called since then - saslprep has been last called, but generated no comments at that time. fullstop issue arose after that - Alexey taking on editorship of gssapi mech draft - digests and cram-md5 updated to support stringprep - plain mech to be clarified. When applying saslprep, is a query string or a stored string, as that affects unassigned characters - example to be added showing no initial first reply - example to be added showing non-empty authorization ID - example to be added showing failure vs success - *not* to clarify SMTP usage or use SMTP instead of ACAP Rob Siemborski (speaking for Alexey): - 2222bis: - discussion of attack if the security layer is *not* dropped on reauthentication: - attack: - client authenticates to realm A (monitored by B) - reauthenticates to realm B w/o dropping the layer - realm B server now has an oracle on the confidentiality layer - the chairs noted that the risk of attack is related to the trust relationships in the server setup - poll of room re: how to handle - 15 to zero in favor of documenting in the security considerations and not altering the SASL requirement - the option of leaving it up to the protocol profile was considered by some to be an even worse choice due to the extra complexity it introduces. - will be taken to list for confirmation of consensus - consider adding text: client should check to verify that a MITM attack didn't remove mechanisms from the list by checking after - believed to be resolved with careful wording Kurt: - last call on saslprep draft - fullstop issue - some discussion on list - Ienup Sung presents: why fullstop != . - defs from unicode: - U+002E defined not just as period but also for decimals - U+3002 has U+002E as reference, not equivalence - U+FF0E (fullwidth period) *is* equivalent to U+002E - NFKC reflects this - ideographics stops are *only* used in text, not as decimal point (this is stricter in Japan and China than in Korea) - ergo: they should only be in the same equivalence class for internet style domain names (IDNA) and *not* in saslprep - - comments [confusing to follow] - Jeff Altman: - wording by Ienup seems to be that decimal *can* be used in text - therefore, *should* do mapping because users might not be able to control it - Marc Crispin:Please provide an example of a real world situation where this is a problem. - Paul Hoffman: - if you believe that normal names that will be used in sasl will include periods that will be used in context-sensitive ways, then do not to the mapping - Ienup: - feels that parens vs bracket in english is an analogous situations - Jeff Altman: - no, saslprep shouldn't always do the mapping; but that mechs should overide that for saslprep usages that specify things like domain-name-like items - Marc Crispin: - does not seem credibile that the mapping is necessary - wants credible example - Nico Williams: - felt that credible example was given, thinks that it may be a UI issue - private-use characters - suggestion by Jeff Altman that private-use char restriction should be removed and replaced with discussion of usages and lack of interoperability - characters not yet in unicode from previous charsets including experimental and those in internal use in corps - ?would require normalization of private-use characters? - Ienup: - saslprep prohibits them - some text cannot be entered without these - there is some need, understand problems and issues need to make clear that this is limited use - Kurt: - cannot just drop prohibition because too much is defined privately - chair: show of hands to go forward with even considering - 4 hands for - 5 hands against - Michel: - extremely bad idea - no semantic defined - not stable - even inside same organization, different usages may exist - no temporal stability - Paul Hoffman: - all that, plus, this is for identifiers and password only - name that requires private use character is unlikely - will be taken back to the list - Rob: SMTP AUTH - proposal to add initial response to IMAP - issue is in the rfcs, it's just not clear - new pop3 and smtp profile drafts - cleanup, add examples, fill in gaps - especially cases showing failing to send initial response - consensus on list was to *not* change examples in sasl plain from ACAP to SMTP - examples of initial client response and server last challenge *will* be added to rfc2222bis - WG wrap up - milestones - GSSAPI I-D is still missing, Alexey says new version should be out by end of November - implementation report to be pushed out because recycling at proposed - (or maybe not? chairs to discuss); base may not need recycling - base is ready for last call - plain has minor tweaks, needs last call - anonymous is ready - saslprep has minor issues - cram-md5 and digest-md5 need a little more work before last call Alexey has dealt with CBC issues but missed cut-off before meeting - base, plain, anonymous, and saslprep before end of year - digest + cram shortly thereafter - gssapi by, say, May? - Bob Morgan - FYI: OASIS has interest in defining a SASL mech doing single-sign-on expect note to mailing list From owner-ietf-sasl Wed Dec 3 11:17:41 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3JHfib076872 for ; Wed, 3 Dec 2003 11:17:41 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3JHf06076871 for ietf-sasl-bks; Wed, 3 Dec 2003 11:17:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-NINETEEN.MIT.EDU [18.187.5.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3JHeib076864 for ; Wed, 3 Dec 2003 11:17:40 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id B1E9D1515F2; Wed, 3 Dec 2003 14:17:39 -0500 (EST) To: Simon Josefsson Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Wed, 03 Dec 2003 14:17:39 -0500 In-Reply-To: (Simon Josefsson's message of "Wed, 03 Dec 2003 19:56:03 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Simon" == Simon Josefsson writes: Simon> If SASLPrepX is guaranteed to behave the same as SASLPrep Simon> for currently assigned characters, there is no problem in Simon> storing SASLPrep prepared strings in the database, and my Simon> text is incorrect. However, in that case, I believe the Simon> guarantee that SASLPrepX(SASLPrep(string)) = Simon> SASLPrepX(string) should be stated in the SASLPrep Simon> document. I believe this guarantee is stated in stringprep. From owner-ietf-sasl Wed Dec 3 11:35:53 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3JZrib077631 for ; Wed, 3 Dec 2003 11:35:53 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3JZruM077630 for ietf-sasl-bks; Wed, 3 Dec 2003 11:35:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3JZpib077624 for ; Wed, 3 Dec 2003 11:35:52 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.10/8.12.10) with ESMTP id hB3JZkrh005664 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 3 Dec 2003 20:35:46 +0100 To: Sam Hartman Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Simon Josefsson X-Payment: hashcash 1.2 0:031203:hartmans@mit.edu:4929e304894508c6 X-Hashcash: 0:031203:hartmans@mit.edu:4929e304894508c6 X-Payment: hashcash 1.2 0:031203:jhutz@cmu.edu:a6a81735d4c0c035 X-Hashcash: 0:031203:jhutz@cmu.edu:a6a81735d4c0c035 X-Payment: hashcash 1.2 0:031203:ietf-sasl@imc.org:90616f6c18f9afc5 X-Hashcash: 0:031203:ietf-sasl@imc.org:90616f6c18f9afc5 Date: Wed, 03 Dec 2003 20:35:33 +0100 In-Reply-To: (Sam Hartman's message of "Wed, 03 Dec 2003 14:17:39 -0500") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: >>>>>> "Simon" == Simon Josefsson writes: > > Simon> If SASLPrepX is guaranteed to behave the same as SASLPrep > Simon> for currently assigned characters, there is no problem in > Simon> storing SASLPrep prepared strings in the database, and my > Simon> text is incorrect. However, in that case, I believe the > Simon> guarantee that SASLPrepX(SASLPrep(string)) = > Simon> SASLPrepX(string) should be stated in the SASLPrep > Simon> document. > > I believe this guarantee is stated in stringprep. I'm sorry to be dense, but can you be more specific? I thought future stringprep profiles were allowed to use Unicode 4.0.0, including the correct normalization tables, but if SASLPrep2 would do so, the above guarantee doesn't hold. Thanks, Simon From owner-ietf-sasl Wed Dec 3 11:43:31 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3JhVib077914 for ; Wed, 3 Dec 2003 11:43:31 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3JhVRc077913 for ietf-sasl-bks; Wed, 3 Dec 2003 11:43:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-NINETEEN.MIT.EDU [18.187.5.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3JhUib077907 for ; Wed, 3 Dec 2003 11:43:30 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id A35FB1515F2; Wed, 3 Dec 2003 14:43:29 -0500 (EST) To: Simon Josefsson Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Wed, 03 Dec 2003 14:43:29 -0500 In-Reply-To: (Simon Josefsson's message of "Wed, 03 Dec 2003 20:35:33 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Simon" == Simon Josefsson writes: Simon> I'm sorry to be dense, but can you be more specific? I Simon> thought future stringprep profiles were allowed to use Simon> Unicode 4.0.0, including the correct normalization tables, Simon> but if SASLPrep2 would do so, the above guarantee doesn't Simon> hold. The problem here being that normalization changed between 3.2 and 4.0 in incompatible ways? Well, that's sort of an open issue within the IETF because that wasn't supposed to happen. Stringprep assumes normalization never changes; we assume that future versions of stringprep onlly change in handling of unassigned codepoints. Unicode has created a mess for us and we have not decided how to deal. From owner-ietf-sasl Wed Dec 3 10:56:22 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3IuMib076217 for ; Wed, 3 Dec 2003 10:56:22 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3IuMVN076216 for ietf-sasl-bks; Wed, 3 Dec 2003 10:56:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3IuKib076197 for ; Wed, 3 Dec 2003 10:56:20 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.10/8.12.10) with ESMTP id hB3IuGrh004892 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 3 Dec 2003 19:56:16 +0100 To: Sam Hartman Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Simon Josefsson X-Payment: hashcash 1.2 0:031203:hartmans@mit.edu:0dcae58eca711d66 X-Hashcash: 0:031203:hartmans@mit.edu:0dcae58eca711d66 X-Payment: hashcash 1.2 0:031203:jhutz@cmu.edu:ab1890be4cc6d30a X-Hashcash: 0:031203:jhutz@cmu.edu:ab1890be4cc6d30a X-Payment: hashcash 1.2 0:031203:ietf-sasl@imc.org:82b60170ff38f502 X-Hashcash: 0:031203:ietf-sasl@imc.org:82b60170ff38f502 Date: Wed, 03 Dec 2003 19:56:03 +0100 In-Reply-To: (Sam Hartman's message of "Wed, 03 Dec 2003 12:21:28 -0500") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: > I mean that this should be a requirement for interoperability in the > long term. If you don't have this requirement, then you may run into > cases where saslprep eventually maps out those characters in the > future. > > Basically, if we require allowunassigned to be false, we guarantee > future interoperability at the cost of refusing to allow people to use > unassigned characters until saslprep is updated. I don't see a conflict with this and the text I proposed, but I'm not sure if you argue for or against the text. In fact, the problem of forward compatible databases was the motivation for my text. The text would help if SASLPrepX(SASLPrep(string)) != SASLPrepX(string) where SASLPrepX is any future revision of SASLPrep. If SASLPrepX is guaranteed to behave the same as SASLPrep for currently assigned characters, there is no problem in storing SASLPrep prepared strings in the database, and my text is incorrect. However, in that case, I believe the guarantee that SASLPrepX(SASLPrep(string)) = SASLPrepX(string) should be stated in the SASLPrep document. "Kurt D. Zeilenga" writes: > In each of the password-based mechanisms (PLAIN, CRAM-MD5, > DIGEST-MD5, etc.), the user provided string is clear a "query" > string and the string which it is compared against (directly > or indirectly) is a "stored" string (regardless of whether > the server stores it locally or in some external systems). This is not the only interpretation. It is possible to consider the SASL library to be performing a query against the HMAC-MD5 oracle to decide whether a Unicode string the library received from the application (possibly ultimately from a database), after the library has prepared it with SASLPrep with AllowUnassigned set to true, is the same secret used by the client. >>If the answer is yes, I don't agree, because that would make CRAM-MD5 >>reject passwords containing characters introduced by Unicode 4.0.0. > > As intended! Until stringprep is updated to detail how these > newly assigned code points are to be handled, we need to exclude > them from appearing in the "stored" password string. The behaviour of inputting Unicode 4.0.0 characters should still be well defined. The current text say nothing about what the server should do, so rejecting the input isn't the only alternative. Thanks, Simon From owner-ietf-sasl Wed Dec 3 12:34:24 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3KYOib080168 for ; Wed, 3 Dec 2003 12:34:24 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3KYONp080167 for ietf-sasl-bks; Wed, 3 Dec 2003 12:34:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3KYMib080162 for ; Wed, 3 Dec 2003 12:34:22 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.10/8.12.10) with ESMTP id hB3KYKrh006966 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 3 Dec 2003 21:34:21 +0100 To: Sam Hartman Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Simon Josefsson X-Payment: hashcash 1.2 0:031203:hartmans@mit.edu:f03ce38d97c49e19 X-Hashcash: 0:031203:hartmans@mit.edu:f03ce38d97c49e19 X-Payment: hashcash 1.2 0:031203:jhutz@cmu.edu:80f7ade3ca434606 X-Hashcash: 0:031203:jhutz@cmu.edu:80f7ade3ca434606 X-Payment: hashcash 1.2 0:031203:ietf-sasl@imc.org:e81851d0b8e5db8d X-Hashcash: 0:031203:ietf-sasl@imc.org:e81851d0b8e5db8d Date: Wed, 03 Dec 2003 21:34:08 +0100 In-Reply-To: (Sam Hartman's message of "Wed, 03 Dec 2003 14:43:29 -0500") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: >>>>>> "Simon" == Simon Josefsson writes: > > > Simon> I'm sorry to be dense, but can you be more specific? I > Simon> thought future stringprep profiles were allowed to use > Simon> Unicode 4.0.0, including the correct normalization tables, > Simon> but if SASLPrep2 would do so, the above guarantee doesn't > Simon> hold. > > The problem here being that normalization changed between 3.2 and 4.0 > in incompatible ways? That's one example of the problem, yes. In general, I didn't find any guarantee that a future version of a stringprep profile must be backwards compatible to the previous version. For SASLPrep, that could be useful, but I haven't found any place that say it must be so. If there isn't, storing the unprepared string in databases appear to be the safe recommendation. (It might be anyway, if the database is shared with other password infrastructures that doesn't use SASLPrep, but that's besides the point.) Thanks, Simon From owner-ietf-sasl Wed Dec 3 12:36:42 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3Kagib080248 for ; Wed, 3 Dec 2003 12:36:42 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3Kagbh080247 for ietf-sasl-bks; Wed, 3 Dec 2003 12:36:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-NINETEEN.MIT.EDU [18.187.5.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3Kafib080242 for ; Wed, 3 Dec 2003 12:36:41 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 92F411515F2; Wed, 3 Dec 2003 15:36:37 -0500 (EST) To: Simon Josefsson Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Wed, 03 Dec 2003 15:36:37 -0500 In-Reply-To: (Simon Josefsson's message of "Wed, 03 Dec 2003 21:34:08 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Simon" == Simon Josefsson writes: Simon> Sam Hartman writes: >>>>>>> "Simon" == Simon Josefsson writes: >> Simon> I'm sorry to be dense, but can you be more specific? I Simon> thought future stringprep profiles were allowed to use Simon> Unicode 4.0.0, including the correct normalization tables, Simon> but if SASLPrep2 would do so, the above guarantee doesn't Simon> hold. >> The problem here being that normalization changed between 3.2 >> and 4.0 in incompatible ways? Simon> That's one example of the problem, yes. In general, I Simon> didn't find any guarantee that a future version of a Simon> stringprep profile must be backwards compatible to the Simon> previous version. For SASLPrep, that could be useful, but Simon> I haven't found any place that say it must be so. If there Simon> isn't, storing the unprepared string in databases appear to Simon> be the safe recommendation. (It might be anyway, if the Simon> database is shared with other password infrastructures that Simon> doesn't use SASLPrep, but that's besides the point.) It's my understanding that the entire IETF internationalization architecture as it depends on stringprep depends on this guarantee. Sort of unfortunate that it is not stated. From owner-ietf-sasl Wed Dec 3 13:06:50 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3L6oib081477 for ; Wed, 3 Dec 2003 13:06:50 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3L6oRM081476 for ietf-sasl-bks; Wed, 3 Dec 2003 13:06:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3L6nib081471 for ; Wed, 3 Dec 2003 13:06:49 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hB3L6glg033478; Wed, 3 Dec 2003 21:06:42 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031203123841.02784828@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 03 Dec 2003 13:05:45 -0800 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-sasl-crammd5-01.txt Cc: Sam Hartman , Jeffrey Hutzelman , ietf-sasl@imc.org In-Reply-To: References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:56 AM 12/3/2003, Simon Josefsson wrote: >"Kurt D. Zeilenga" writes: > >> In each of the password-based mechanisms (PLAIN, CRAM-MD5, >> DIGEST-MD5, etc.), the user provided string is clear a "query" >> string and the string which it is compared against (directly >> or indirectly) is a "stored" string (regardless of whether >> the server stores it locally or in some external systems). > >This is not the only interpretation. It is possible to consider the >SASL library to be performing a query against the HMAC-MD5 oracle to >decide whether a Unicode string the library received from the >application (possibly ultimately from a database), after the library >has prepared it with SASLPrep with AllowUnassigned set to true, is the >same secret used by the client. Well, maybe the language I used was not clear enough. My point is that the mechanism specification must clearly state which strings are query strings and which strings are stored strings and ensure that two query strings prepared by different implementations are not (directly or indirectly) compared. The client copy of the user name and shared secret should be defined as query strings and, hence, unassigned code points are allowed to appear in the prepared output. The server copy of the user name and shared secret should be viewed as stored strings and, hence, unassigned code points are not allowed to appear in the prepared output. The draft needs to be revised to make this clear. Kurt From owner-ietf-sasl Wed Dec 3 13:36:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3LaYib082725 for ; Wed, 3 Dec 2003 13:36:34 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3LaY4I082724 for ietf-sasl-bks; Wed, 3 Dec 2003 13:36:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3LaWib082719 for ; Wed, 3 Dec 2003 13:36:32 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hB3LaX5G028697; Wed, 3 Dec 2003 16:36:33 -0500 Date: Wed, 3 Dec 2003 16:36:33 -0500 (EST) From: Rob Siemborski To: Sam Hartman cc: ietf-sasl@imc.org Subject: Re: Moving to rfc2222bis last call In-Reply-To: <20031201174409.A27F91515F2@konishi-polis.mit.edu> Message-ID: References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 1 Dec 2003, Sam Hartman wrote: > What are we still waiting on before the next last call of this > document? >From the minutes, we need to see an updated security considerations section (for the MITM attack), and we need examples for the initial client response and server last sends. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Wed Dec 3 14:28:20 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3MSJib086040 for ; Wed, 3 Dec 2003 14:28:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3MSJka086039 for ietf-sasl-bks; Wed, 3 Dec 2003 14:28:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3MSIib086034 for ; Wed, 3 Dec 2003 14:28:18 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hB3MSKlg034367 for ; Wed, 3 Dec 2003 22:28:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031203141404.0913d728@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 03 Dec 2003 14:27:23 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: PLAIN and unassigned characters (Was: draft-ietf-sasl-crammd5-01.txt) In-Reply-To: <6.0.0.22.0.20031203123841.02784828@127.0.0.1> References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> <6.0.0.22.0.20031203123841.02784828@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: In consideration of the on-going CRAM-MD5 unassigned code point discussions, I reviewed draft-ietf-sasl-plain-xx.txt handling in this area and found that a few additional words would add clarity in this area. Hence, I'd like to make the following change: @@ -151,10 +151,12 @@ The presented authentication identity and password strings are not to be compared directly with stored strings. The server SHALL first prepare authentication identity and password strings using the [SASLPrep] profile of the [StringPrep] algorithm. +Per Section 7 of [StringPrep], unassigned code points may appear in +prepared presented (query) strings but are prohibited in stored strings. If preparation fails or results in an empty string, verification SHALL fail. If the server stores only the hash of expected string, the string MUST be prepared before generation of the hash. (+ indicates new text) Additionally (as previously discussed), I'll update the pseudo code such that SASLprep() takes a second argument as follows: +The second parameter of the SASLprep function, when true, indicates +that the input string is a "query" string [StringPrep] and, hence, +unassigned code points are allowed. When the SASLprep function is +called to prepared the password prior to computing the stored hash, +the second parameter would be false as unassigned code points are +not allowed in "stored strings" [StringPrep]. Kurt At 01:05 PM 12/3/2003, Kurt D. Zeilenga wrote: >At 10:56 AM 12/3/2003, Simon Josefsson wrote: >>"Kurt D. Zeilenga" writes: >> >>> In each of the password-based mechanisms (PLAIN, CRAM-MD5, >>> DIGEST-MD5, etc.), the user provided string is clear a "query" >>> string and the string which it is compared against (directly >>> or indirectly) is a "stored" string (regardless of whether >>> the server stores it locally or in some external systems). >> >>This is not the only interpretation. It is possible to consider the >>SASL library to be performing a query against the HMAC-MD5 oracle to >>decide whether a Unicode string the library received from the >>application (possibly ultimately from a database), after the library >>has prepared it with SASLPrep with AllowUnassigned set to true, is the >>same secret used by the client. > >Well, maybe the language I used was not clear enough. > >My point is that the mechanism specification must clearly >state which strings are query strings and which strings are >stored strings and ensure that two query strings prepared >by different implementations are not (directly or indirectly) >compared. > >The client copy of the user name and shared secret should >be defined as query strings and, hence, unassigned code points >are allowed to appear in the prepared output. The server >copy of the user name and shared secret should be viewed >as stored strings and, hence, unassigned code points are not >allowed to appear in the prepared output. > >The draft needs to be revised to make this clear. > >Kurt From owner-ietf-sasl Wed Dec 3 15:36:04 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3Na3ib088696 for ; Wed, 3 Dec 2003 15:36:03 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3Na3sT088695 for ietf-sasl-bks; Wed, 3 Dec 2003 15:36:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3Na0ib088689 for ; Wed, 3 Dec 2003 15:36:02 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hB3Na2lg035083 for ; Wed, 3 Dec 2003 23:36:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031203153456.09152800@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 03 Dec 2003 15:35:04 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: PLAIN 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: Here are the updated examples section: This section provides examples of PLAIN authentication exchanges. The examples are intended to help the readers understand the above text. The examples are not definitive. "C:" and "S:" indicate lines sent by the client and server respectively. "" represents a single NUL (U+0000) character. The Application Configuration Access Protocol ([ACAP]) is used in the examples. The first example shows how the PLAIN mechanism might be used for user authentication. S: * ACAP (SASL "CRAM-MD5") (STARTTLS) C: a001 STARTTLS S: a001 OK "Begin TLS negotiation now" S: * ACAP (SASL "CRAM-MD5" "PLAIN") C: a002 AUTHENTICATE "PLAIN" S: + "" C: {21} C: timtanstaaftanstaaf S: a002 OK "Authenticated" The second example shows how the PLAIN mechanism might be used to assuming the identity of another user. In this example, the server rejects the request. Also, this example makes use of the protocol optional initial response capability to eliminate a round-trip. S: * ACAP (SASL "CRAM-MD5") (STARTTLS) C: a001 STARTTLS S: a001 OK "Begin TLS negotiation now" S: * ACAP (SASL "CRAM-MD5" "PLAIN") C: a002 AUTHENTICATE "PLAIN" {19+} C: JaneJohnxipj3plmq S: a002 NO "Not authorized to assume asserted identity" From owner-ietf-sasl Wed Dec 3 15:37:56 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3Nbuib088745 for ; Wed, 3 Dec 2003 15:37:56 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3Nbu1k088744 for ietf-sasl-bks; Wed, 3 Dec 2003 15:37:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB3Nbsib088739 for ; Wed, 3 Dec 2003 15:37:55 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa14075; 3 Dec 2003 18:37 EST Date: Wed, 03 Dec 2003 18:37:13 -0500 From: Jeffrey Hutzelman To: Simon Josefsson , Sam Hartman cc: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt Message-ID: <58040000.1070494633@minbar.fac.cs.cmu.edu> In-Reply-To: References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wednesday, December 03, 2003 19:56:03 +0100 Simon Josefsson wrote: > I don't see a conflict with this and the text I proposed, but I'm not > sure if you argue for or against the text. In fact, the problem of > forward compatible databases was the motivation for my text. The text > would help if SASLPrepX(SASLPrep(string)) != SASLPrepX(string) where > SASLPrepX is any future revision of SASLPrep. Yeah; that's supposed to be a guarantee. Part of this is spelled out in RFC2454, at the end of section 3 and in section 7.1: Authors of profiles of this document need to consider the effects of changing the mapping of any currently-assigned character when updating their profiles. Adding a new mapping for a currently- assigned character, or changing an existing mapping, could cause a variance between the behavior of systems that have been updated and systems that have not been updated. A subsequent version of a profile that references a newer version of a repertoire with new code points will inherently have some code points move from category U to either D, MN, or AO. For backwards compatibility, a subsequent version of a profile MUST NOT move code points from any other category. That is, current AO, MN, or D code points MUST NOT ever change to a different category. The rest comes from Unicode itself, which guarantees that normalizations for existing code points will not change. Sadly, it appears the UTC has been willing to violate that guarantee in some cases. > This is not the only interpretation. It is possible to consider the > SASL library to be performing a query against the HMAC-MD5 oracle to > decide whether a Unicode string the library received from the > application (possibly ultimately from a database), after the library > has prepared it with SASLPrep with AllowUnassigned set to true, is the > same secret used by the client. This critical issue is that for servers where a partial MD5 context is stored based on the shared secret, the secret MUST first be prepared according to SASLprep. In this case, the secret needs to be treated as a storage string -- there's no way to reverse the context establishment, so if the string was not normalized correctly to begin with, you can't go back and fix it when you upgrade. Thus, unassigned code points MUST NOT be permitted in such a case. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA > >>> If the answer is yes, I don't agree, because that would make CRAM-MD5 >>> reject passwords containing characters introduced by Unicode 4.0.0. >> >> As intended! Until stringprep is updated to detail how these >> newly assigned code points are to be handled, we need to exclude >> them from appearing in the "stored" password string. > > The behaviour of inputting Unicode 4.0.0 characters should still be > well defined. The current text say nothing about what the server > should do, so rejecting the input isn't the only alternative. > > Thanks, > Simon > > > From owner-ietf-sasl Thu Dec 4 11:13:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4JDYib017771 for ; Thu, 4 Dec 2003 11:13:34 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB4JDYcc017770 for ietf-sasl-bks; Thu, 4 Dec 2003 11:13:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4JDWib017761 for ; Thu, 4 Dec 2003 11:13:32 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.9) with ESMTP id hB4JDY50001433 for ; Thu, 4 Dec 2003 19:13:34 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031204105707.03c7d860@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 04 Dec 2003 11:12:35 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Proposed new slate of milestones for SASL WG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The chairs propose updating our slate of milestones to: Done Submit revised SASL (+ EXTERNAL) I-D Done Submit revised SASL ANONYMOUS I-D Done Submit revised SASL PLAIN I-D Done Submit revised SASL CRAM-MD5 I-D Done Submit revised SASL DIGEST-MD5 I-D Done Submit revised SASL GSSAPI I-D Jan 04 Submit SASL (+ EXTERNAL), SASLprep, ANONYMOUS, PLAIN to IESG for consideration as Proposed Standards Feb 04 Submit CRAM-MD5 to IESG for consideration as a Proposed Standard Mar 04 Submit DIGEST-MD5 to IESG for consideration as a Proposed Standard May 04 Submit GSSAPI to IESG for consideration as a Proposed Standard Jun 04 Provide implementation report plan (with milestones) Aug 04 Revise charter or conclude Note that the milestone dates are basically those suggested at IETF#58 but slipped a month or so. Note as well that this slate calls for all of the revised SASL specifications, including the rfc2222bis I-D, to be recycled at Proposed. This is mainly due to the introduction of SASLprep (which even the rfc2222bis I-D normatively references). If you have comments/concerns regarding this slate, please post them within the next week or so. The chairs plan on making a decision regarding what slate of milestones to progressed to our AD by 19th of this month. Kurt, SASL WG co-chair From owner-ietf-sasl Thu Dec 4 18:21:50 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB52Loib038132 for ; Thu, 4 Dec 2003 18:21:50 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB52LoSW038131 for ietf-sasl-bks; Thu, 4 Dec 2003 18:21:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB52Lmib038123 for ; Thu, 4 Dec 2003 18:21:49 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from [192.168.1.102] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id hB52Lm40007250; Thu, 4 Dec 2003 19:21:49 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Thu, 04 Dec 2003 18:21:45 -0800 From: Lyndon Nerenberg To: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: PLAIN examples Message-ID: <2147483647.1070562105@[192.168.42.6]> In-Reply-To: <6.0.0.22.0.20031203153456.09152800@127.0.0.1> References: <6.0.0.22.0.20031203153456.09152800@127.0.0.1> X-Mailer: Mulberry/3.1.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on orthanc.ca Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > C: JaneJohnxipj3plmq I would change Jane and John to something not quite so similar, just to make the distinction more obvious. --lyndon From owner-ietf-sasl Thu Dec 4 19:07:33 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB537Xib040211 for ; Thu, 4 Dec 2003 19:07:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB537XJX040210 for ietf-sasl-bks; Thu, 4 Dec 2003 19:07:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB537Tib040204 for ; Thu, 4 Dec 2003 19:07:31 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from [192.168.1.102] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id hB537M40007527; Thu, 4 Dec 2003 20:07:23 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Thu, 04 Dec 2003 19:07:19 -0800 From: Lyndon Nerenberg To: "Kurt D. Zeilenga" , Simon Josefsson cc: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt Message-ID: <2147483647.1070564839@[192.168.42.6]> In-Reply-To: <6.0.0.22.0.20031203123841.02784828@127.0.0.1> References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> <6.0.0.22.0.20031203123841.02784828@127.0.0.1> X-Mailer: Mulberry/3.1.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on orthanc.ca Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Wednesday, December 3, 2003 1:05 PM -0800 "Kurt D. Zeilenga" wrote: > The client copy of the user name and shared secret should > be defined as query strings and, hence, unassigned code points > are allowed to appear in the prepared output. The server > copy of the user name and shared secret should be viewed > as stored strings and, hence, unassigned code points are not > allowed to appear in the prepared output. > > The draft needs to be revised to make this clear. I'm having no luck coming up with text that explains this clearly. And I'm still not convinced that this should be discussed in the mechanism spec, since it applies much more widely than just CRAM. 2222bis seems to me to be a better place to lay this out. That said, I have to rev the CRAM draft again for other (editorial) reasons, so if someone can come up with a diff to -01 I'll incorporate it. (Or is Kurt's paragraph above clear enough?) --lyndon From owner-ietf-sasl Fri Dec 5 04:19:35 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5CJZib037545 for ; Fri, 5 Dec 2003 04:19:35 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5CJYWv037544 for ietf-sasl-bks; Fri, 5 Dec 2003 04:19:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5CJSib037537 for ; Fri, 5 Dec 2003 04:19:34 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.253]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Fri, 5 Dec 2003 12:23:00 +0000 Message-ID: <3FD077CB.9090101@isode.com> Date: Fri, 05 Dec 2003 12:19:23 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Moving to rfc2222bis last call References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> In-Reply-To: <20031201174409.A27F91515F2@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: >What are we still waiting on before the next last call of this >document? > Rob's assessment is right. I also need to work on some issues raised by Hallvard. I am a bit busy at the moment. I will try to push a new revision in a week or so. Alexey From owner-ietf-sasl Fri Dec 5 08:14:45 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5GEjib050166 for ; Fri, 5 Dec 2003 08:14:45 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5GEjER050165 for ietf-sasl-bks; Fri, 5 Dec 2003 08:14:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-NINETEEN.MIT.EDU [18.187.5.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5GEhib050158 for ; Fri, 5 Dec 2003 08:14:43 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 15DA71515F2; Fri, 5 Dec 2003 11:14:38 -0500 (EST) To: Lyndon Nerenberg Cc: "Kurt D. Zeilenga" , Simon Josefsson , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> <6.0.0.22.0.20031203123841.02784828@127.0.0.1> <2147483647.1070564839@[192.168.42.6]> From: Sam Hartman Date: Fri, 05 Dec 2003 11:14:38 -0500 In-Reply-To: <2147483647.1070564839@[192.168.42.6]> (Lyndon Nerenberg's message of "Thu, 04 Dec 2003 19:07:19 -0800") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Lyndon" == Lyndon Nerenberg writes: Lyndon> I'm having no luck coming up with text that explains this Lyndon> clearly. And I'm still not convinced that this should be Lyndon> discussed in the mechanism spec, since it applies much Lyndon> more widely than just CRAM. 2222bis seems to me to be a Lyndon> better place to lay this out. I disagree. How to prepare authentication identities is entirely a mechanism matter. The base spec can point out the general concern but cannot constrain what the mechanism does. For example various GSSAPI mechanisms may do much more complicated stringprep. Kerberos certainly will. From owner-ietf-sasl Fri Dec 5 20:33:43 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB64Xhib089893 for ; Fri, 5 Dec 2003 20:33:43 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB64XhE5089892 for ietf-sasl-bks; Fri, 5 Dec 2003 20:33:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB64Xfib089887 for ; Fri, 5 Dec 2003 20:33:41 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.9) with ESMTP id hB64Xia9025211 for ; Sat, 6 Dec 2003 04:33:44 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031205203112.027483c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 05 Dec 2003 20:32:43 -0800 To: ietf-sasl@imc.org From: "Sebastian Petrescu" Subject: sasl + pam : ietf-sasl 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: Hello. I do have a problem. I'm trying to install postfix + sasl with pam support. saslauthd -v saslauthd 2.1.17 authentication mechanisms: getpwent rimap shadow I do have pam installed on my system .. and I'v vonfigured sasl: ./configure --prefix=3D/usr --enable-anon --enable-plain --enable-login --disable-krb4 --with-pam --with-saslauthd=3D/var/run/saslauthd = --with-plugindir=3D/usr/lib/sasl2 --libdir=3D/usr/lib/sasl2 = --with-plugindir=3D/usr/lib/sasl2 |grep pam configure: WARNING: Disabling GSSAPI - no include files found configure: running /bin/sh './configure' --prefix=3D/usr/local '--enable-anon' '--enable-plain' '--enable-login' '--disable-krb4' '--with-saslauthd=3D/var/run/saslauthd' '--libdir=3D/usr/lib/sasl2' '--with-plugindir=3D/usr/lib/sasl2' '--with-pam=3D/lib/security' --cache-file=3D.././config.cache --srcdir=3D. configure: WARNING: Disabling GSSAPI - no include files found checking for pam_start in -lpam... (cached) no I do have pam installed.. I have recompiled pam and installed latest libraries. Can someone please give me a hint ? From owner-ietf-sasl Fri Dec 5 21:10:19 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB65AJib091480 for ; Fri, 5 Dec 2003 21:10:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB65AJDJ091479 for ietf-sasl-bks; Fri, 5 Dec 2003 21:10:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB65AIib091474 for ; Fri, 5 Dec 2003 21:10:18 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.9) with ESMTP id hB65ALa9025553; Sat, 6 Dec 2003 05:10:21 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031205210329.026fd4f0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 05 Dec 2003 21:09:20 -0800 To: "Sebastian Petrescu" From: "Kurt D. Zeilenga" Subject: Re: sasl + pam : ietf-sasl Cc: ietf-sasl@imc.org In-Reply-To: <6.0.0.22.0.20031205203112.027483c8@127.0.0.1> References: <6.0.0.22.0.20031205203112.027483c8@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: Sebastian, Your post is off-topic. This list is reserved for discussions related to the standardization of SASL. Your post would more appropriately be directed to list specific to the software you are using. It appears you are using Cyrus SASL, hence I suggest you direct your enquiry to lists.andrew.cmu.edu>. Kurt, IETF SASL WG Co-chair At 08:32 PM 12/5/2003, Sebastian Petrescu wrote: > Hello. > I do have a problem. I'm trying to install postfix + sasl with pam support. >saslauthd -v >saslauthd 2.1.17 >authentication mechanisms: getpwent rimap shadow > >I do have pam installed on my system .. and I'v vonfigured sasl: >./configure --prefix=3D/usr --enable-anon --enable-plain --enable-login --disable-krb4 --with-pam --with-saslauthd=3D/var/run/saslauthd = >--with-plugindir=3D/usr/lib/sasl2 --libdir=3D/usr/lib/sasl2 = >--with-plugindir=3D/usr/lib/sasl2 |grep pam > >configure: WARNING: Disabling GSSAPI - no include files found >configure: running /bin/sh './configure' --prefix=3D/usr/local '--enable-anon' '--enable-plain' '--enable-login' '--disable-krb4' '--with-saslauthd=3D/var/run/saslauthd' '--libdir=3D/usr/lib/sasl2' '--with-plugindir=3D/usr/lib/sasl2' '--with-pam=3D/lib/security' --cache-file=3D.././config.cache --srcdir=3D. >configure: WARNING: Disabling GSSAPI - no include files found >checking for pam_start in -lpam... (cached) no > > >I do have pam installed.. I have recompiled pam and installed latest libraries. > > Can someone please give me a hint ? From owner-ietf-sasl Sat Dec 6 20:31:35 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB74VZib022099 for ; Sat, 6 Dec 2003 20:31:35 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB74VZNh022098 for ietf-sasl-bks; Sat, 6 Dec 2003 20:31:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB74VPib022089 for ; Sat, 6 Dec 2003 20:31:32 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.10/8.12.10) with ESMTP id hB74V6AU007454 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 7 Dec 2003 05:31:11 +0100 To: Jeffrey Hutzelman Cc: Sam Hartman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> <58040000.1070494633@minbar.fac.cs.cmu.edu> From: Simon Josefsson X-Payment: hashcash 1.2 0:031207:jhutz@cmu.edu:3158a3f29a2de7ad X-Hashcash: 0:031207:jhutz@cmu.edu:3158a3f29a2de7ad X-Payment: hashcash 1.2 0:031207:hartmans@mit.edu:9a7fb563e1dda382 X-Hashcash: 0:031207:hartmans@mit.edu:9a7fb563e1dda382 X-Payment: hashcash 1.2 0:031207:ietf-sasl@imc.org:22c45d20771641d2 X-Hashcash: 0:031207:ietf-sasl@imc.org:22c45d20771641d2 Date: Sun, 07 Dec 2003 05:30:47 +0100 In-Reply-To: <58040000.1070494633@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Wed, 03 Dec 2003 18:37:13 -0500") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman writes: > On Wednesday, December 03, 2003 19:56:03 +0100 Simon Josefsson > wrote: > >> I don't see a conflict with this and the text I proposed, but I'm not >> sure if you argue for or against the text. In fact, the problem of >> forward compatible databases was the motivation for my text. The text >> would help if SASLPrepX(SASLPrep(string)) != SASLPrepX(string) where >> SASLPrepX is any future revision of SASLPrep. > > Yeah; that's supposed to be a guarantee. Part of this is spelled out > in RFC2454, at the end of section 3 and in section 7.1: > > Authors of profiles of this document need to consider the effects of > changing the mapping of any currently-assigned character when > updating their profiles. Adding a new mapping for a currently- > assigned character, or changing an existing mapping, could cause a > variance between the behavior of systems that have been updated and > systems that have not been updated. This is not much of a guarantee. To me, the wording suggest that stringprep profiles actually can be backwards incompatible, if the designers feel the benefits outweigh the costs that are mentioned. > A subsequent version of a profile that references a newer version of > a repertoire with new code points will inherently have some code > points move from category U to either D, MN, or AO. For backwards > compatibility, a subsequent version of a profile MUST NOT move code > points from any other category. That is, current AO, MN, or D code > points MUST NOT ever change to a different category. This is good text, and I thought it would take of this problem. However, it doesn't appear to be that simple, because it continue to say: Applications creating queries MUST treat U code points as if they were AO when preparing the query to be entered in the process described by a profile of stringprep. Those applications MAY optionally have a preprocessor that provide stricter checks: treating unassigned code points in the input as errors, or warning the user about the fact that the code point is unassigned in the version of a profile that the software is based on; such a choice is a local matter for the software. So the result is that if the profile is used with AllowUnassigned set to true, the computed strings are not necessarily forwards compatible. Furthermore, one of the three ways forward presented in draft-faltstrom-unicode-synchronisation-00, to support new Unicode versions, include breaking backwards compatibility in stringprep profiles. To summarize, I don't believe the SASLPrep2(SASLPrep1(string)) == SASLPrep2(string) guarantee hold universally, nor follow from the core document. This problem can be solved by adding a discussion in the SASLPrep document that contain some guarantee that will hold for future versions of the SASLPrep profile. Perhaps even explicitly mention which path in draft-faltstrom-unicode-synchronisation-00 SASLPrep will follow. Alternatively, you could recommend applications to store the unprepared original passwords, which will be safe regardless of what SASLPrep will behave in the future. I prefer this approach, but judging from the responses to my proposed text for CRAM-MD5, perhaps there isn't consensus about that. Finally, each mechanism using SASLPrep should also say when and how AllowUnassigned is set. Thanks, Simon From owner-ietf-sasl Sun Dec 7 21:45:47 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB85jlib098527 for ; Sun, 7 Dec 2003 21:45:47 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB85jlXm098526 for ietf-sasl-bks; Sun, 7 Dec 2003 21:45:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mariner.pc.cs.cmu.edu (dsl093-061-085.pit1.dsl.speakeasy.net [66.93.61.85]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB85jfib098482 for ; Sun, 7 Dec 2003 21:45:43 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa04100; 8 Dec 2003 0:45 EST Date: Mon, 08 Dec 2003 00:44:59 -0500 From: Jeffrey Hutzelman To: Simon Josefsson cc: Jeffrey Hutzelman , Sam Hartman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt Message-ID: <3750000.1070862299@mariner.pc.cs.cmu.edu> In-Reply-To: References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> <58040000.1070494633@minbar.fac.cs.cmu.edu> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sunday, December 07, 2003 05:30:47 +0100 Simon Josefsson wrote: > Jeffrey Hutzelman writes: > >> On Wednesday, December 03, 2003 19:56:03 +0100 Simon Josefsson >> wrote: >> >>> I don't see a conflict with this and the text I proposed, but I'm not >>> sure if you argue for or against the text. In fact, the problem of >>> forward compatible databases was the motivation for my text. The text >>> would help if SASLPrepX(SASLPrep(string)) != SASLPrepX(string) where >>> SASLPrepX is any future revision of SASLPrep. >> >> Yeah; that's supposed to be a guarantee. Part of this is spelled out >> in RFC2454, at the end of section 3 and in section 7.1: >> >> Authors of profiles of this document need to consider the effects of >> changing the mapping of any currently-assigned character when >> updating their profiles. Adding a new mapping for a currently- >> assigned character, or changing an existing mapping, could cause a >> variance between the behavior of systems that have been updated and >> systems that have not been updated. > > This is not much of a guarantee. To me, the wording suggest that > stringprep profiles actually can be backwards incompatible, if the > designers feel the benefits outweigh the costs that are mentioned. Yes, I believe that's exactly what it says. It may not seem like much of a guarantee, but it's the best we can possibly have. Designers of future versions of a profile will always be able to break backward compatibility, no matter what we do -- no "requirement" we write now can be effective against an IETF concensus in the future. >> A subsequent version of a profile that references a newer version of >> a repertoire with new code points will inherently have some code >> points move from category U to either D, MN, or AO. For backwards >> compatibility, a subsequent version of a profile MUST NOT move code >> points from any other category. That is, current AO, MN, or D code >> points MUST NOT ever change to a different category. > > This is good text, and I thought it would take of this problem. > However, it doesn't appear to be that simple, because it continue to > say: > > Applications creating queries MUST treat U code points as if they > were AO when preparing the query to be entered in the process > described by a profile of stringprep. Those applications MAY > optionally have a preprocessor that provide stricter checks: treating > unassigned code points in the input as errors, or warning the user > about the fact that the code point is unassigned in the version of a > profile that the software is based on; such a choice is a local > matter for the software. > > So the result is that if the profile is used with AllowUnassigned set > to true, the computed strings are not necessarily forwards compatible. That is correct - if you apply stringprep with AllowUnassigned set to TRUE, there is no guarantee that two implementations will produce the same result given the same input. But that's OK for a query string that's going to be used "once", right now -- the worst thing that can happen is that it doesn't match when it "should". However, for a string that's going to be stored long-term, preparing it incorrectly now is fatal; it will then _NEVER_ match a correctly prepared string. If there are unassigned code points, then you can't know if you're preparing it correctly; the easiest solution to this problem is to raise an exception now, and refuse to store a string if you don't know how to prepare it correctly. That's what setting AllowUnassigned to FALSE does. So I'll go back to my original statement -- IF a server is going to prepare strings in advance (which it cannot avoid if it's going to precompute a partial MD5 context), then it MUST set AllowUnassigned to FALSE and reject strings which contain unassigned code points. > Furthermore, one of the three ways forward presented in > draft-faltstrom-unicode-synchronisation-00, to support new Unicode > versions, include breaking backwards compatibility in stringprep > profiles. I've not had a chance to read that document yet, so I can't comment on it. > To summarize, I don't believe the SASLPrep2(SASLPrep1(string)) == > SASLPrep2(string) guarantee hold universally, nor follow from the core > document. > > This problem can be solved by adding a discussion in the SASLPrep > document that contain some guarantee that will hold for future > versions of the SASLPrep profile. Perhaps even explicitly mention > which path in draft-faltstrom-unicode-synchronisation-00 SASLPrep will > follow. We can't make an effective guarantee against a future IETF concensus. But given the text in RFC2454, I do agree we need to address the issue, and express the intent that the mappings of code points not in class U will not change in future versions of the specification. > Alternatively, you could recommend applications to store the > unprepared original passwords, which will be safe regardless of what > SASLPrep will behave in the future. I prefer this approach, but > judging from the responses to my proposed text for CRAM-MD5, perhaps > there isn't consensus about that. I get the impression that people like the idea of storing a partial MD5 context, even though doing so doesn't offer much protection. If servers are going to do this, I think they should be REQUIRED to prepare with AllowUnassigned set FALSE. OTOH, if they're going to store passwords, I agree that storing unprepared passwords allows for the greatest chance of future interoperability. > Finally, each mechanism using SASLPrep should also say when and how > AllowUnassigned is set. Absolutely. -- Jeff From owner-ietf-sasl Sun Dec 14 09:02:10 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBEH2Aib075484 for ; Sun, 14 Dec 2003 09:02:10 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBEH2Aqf075483 for ietf-sasl-bks; Sun, 14 Dec 2003 09:02:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBEH1wib075470 for ; Sun, 14 Dec 2003 09:02:07 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust128.tnt110.lnd4.gbr.da.uu.net [62.188.174.128]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 14 Dec 2003 17:06:15 +0000 Message-ID: <3FDC8C1B.6070705@isode.com> Date: Sun, 14 Dec 2003 16:13:15 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: Moving to rfc2222bis last call References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >Sam Hartman writes: > > >>What are we still waiting on before the next last call of this >>document? >> >> > >I think this document needs another version before it is ready for last >call. Here is the unfinished business I'm aware of: > >------------------------------------------------------------------------ > >The 'suggested text about multiple SASL mechanisms' thread. > > I think this is done. >------------------------------------------------------------------------ > >Subject: Re: rfc2222bis: protocol profile? >From: Hallvard B Furuseth >Date: Mon, 10 Nov 2003 08:10:22 +0100 >Message-Id: >URL: http://www.imc.org/ietf-sasl/mail-archive/msg01304.html > >What belongs in the protocol profile? > > I will ignore this one, unless you have a specific suggestion/text. I am not sure I can give you a generic future proof advice. >------------------------------------------------------------------------ > >Subject: draft-ietf-sasl-rfc2222bis-02.txt section 4.2 >From: Tony Hansen >Date: Thu, 06 Nov 2003 12:02:22 -0500 >Message-ID: <3FAA7E9E.3080704@att.com> >URL: http://www.imc.org/ietf-sasl/mail-archive/msg01278.html > >Split section 4.2 (Authorization identities and proxy authentication). >It appears to be mixing two totally different discussions together in a >slightly confusing mess. > This is done. I had to merge my recent changes with the proposed text. >------------------------------------------------------------------------ > >The 'selects no security layer' thread. I've lost track of this one and >will have to reread it. But originally all I wanted was to clarify that >specific phrase: either to 'does not select a security layer' or >'selects that there shall be no security layer', or whatever else is >meant. That has not been done yet. > > I think I've addressed the particular issue by saying that mechanism that are incapable of negotiating a security layer always select "no layer". Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Mon Dec 15 01:56:11 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBF9uBib081505 for ; Mon, 15 Dec 2003 01:56:11 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBF9uBIe081504 for ietf-sasl-bks; Mon, 15 Dec 2003 01:56:11 -0800 (PST) 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.10/8.12.8) with ESMTP id hBF9u4ib081451 for ; Mon, 15 Dec 2003 01:56:05 -0800 (PST) (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 1AVpSL-0005vd-Lj; Mon, 15 Dec 2003 10:56:01 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.14) id 1AVpSK-0000iZ-H1; Mon, 15 Dec 2003 10:56:00 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AVpSK-0006nn-00; Mon, 15 Dec 2003 10:56:00 +0100 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Moving to rfc2222bis last call In-Reply-To: <3FDC8C1B.6070705@isode.com> References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> <3FDC8C1B.6070705@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 15 Dec 2003 10:56:00 +0100 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=-4.9, required 12, BAYES_00 -4.90) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >> Subject: Re: rfc2222bis: protocol profile? >> From: Hallvard B Furuseth >> Date: Mon, 10 Nov 2003 08:10:22 +0100 >> Message-Id: >> URL: http://www.imc.org/ietf-sasl/mail-archive/msg01304.html >> >> What belongs in the protocol profile? > > I will ignore this one, unless you have a specific suggestion/text. > I am not sure I can give you a generic future proof advice. I can't offer any suggestions because I don't know what belongs there. I think what I'm really missing is a description of the purpose of the protocol profile. What will it be used for? What is it _not_ intended to be used for? Knowing that, the reader (and I) can judge for himself what should go in it, besides the mandatory items. >> The 'selects no security layer' thread. I've lost track of this one and >> will have to reread it. But originally all I wanted was to clarify that >> specific phrase: either to 'does not select a security layer' or >> 'selects that there shall be no security layer', or whatever else is >> meant. That has not been done yet. > > I think I've addressed the particular issue by saying that mechanism > that are incapable of negotiating a security layer always select "no layer". OK, if the quotes are in place, or otherwise the new wording can't be interpreted as "doesn't select a (new) layer". -- Hallvard From owner-ietf-sasl Mon Dec 15 03:03:28 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFB3Rib089148 for ; Mon, 15 Dec 2003 03:03:27 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFB3RoW089147 for ietf-sasl-bks; Mon, 15 Dec 2003 03:03:27 -0800 (PST) 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.10/8.12.8) with ESMTP id hBFB3Pib089112 for ; Mon, 15 Dec 2003 03:03:25 -0800 (PST) (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 1AVqVW-0000MH-RY for ietf-sasl@imc.org; Mon, 15 Dec 2003 12:03:22 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AVqVN-0006ez-Kf for ietf-sasl@imc.org; Mon, 15 Dec 2003 12:03:13 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AVqVN-0006y4-00 for ietf-sasl@imc.org; Mon, 15 Dec 2003 12:03:13 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: ANONYMOUS In-Reply-To: References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 15 Dec 2003 12:03:13 +0100 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=-4.9, required 12, BAYES_00 -4.90) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [anon] section 4 (Security Considerations) says: > The ANONYMOUS mechanism grants access to information by anyone. For > this reason it should be disabled by default so the administrator can > make an explicit decision to enable it. I disagree. I see no reason to disable ANONYMOUS as long as ANONYMOUS 'authentication' is treated as equivalent to no authentication rather than e.g. as authentication with a password. What is needed is a securicy consideration that ANONYMOUS must not (or MUST NOT?) be enabled unless it is treated specially in this respect. If anon is treated as no auth, some other security considerations disappear too, since they are no different from if the user did not authenticate: > If the anonymous user has any write privileges, a denial of service > attack is possible by filling up all available space. This can be > prevented by disabling all write access by anonymous users. > If anonymous users have read and write access to the same area, the > server can be used as a communication mechanism to anonymously > exchange information. (...) > If the anonymous user can run many expensive operations (e.g., an IMAP > SEARCH BODY command), this could enable a denial of service attack. > While servers may impose a limit on the number of anonymous users, it > is noted that such limits enable denial of service attacks and should > be used with caution. Also, > Anonymous connections are susceptible to man in the middle attacks > which view or alter the data transferred. Clients and servers are > encouraged to support external integrity and encryption mechanisms. It's not that the connection is anonymous which makes it suspectible, but that [anon] provides no SASL security layer. Also, in an earlier thread, I wrote: >Alexey Melnikov writes: >>Kurt D. Zeilenga wrote: >>>At 04:45 PM 11/5/2003, Hallvard B Furuseth wrote: >>> >>>> Looking over the various SASL drafts, I miss one piece of functionality: >>>> To authenticate anonymously, removing any SASL layer, but still >>>> providing an unauthenticated ID (e.g. for logging purposes). >>>> >> How is this different from ANONYMOUS (except for @ sign requirement). > > That's the difference. If there is nothing special about the '@' > character in the underlying auth IDs, then the exclusion of names with > '@' in them is unnatural. Though one could of course introduce a > private hack like using \ for a quote character and type @ as \40, or > something. That reminds me: Would it be appropriate to put something like this in [anon]? A protocol using the ANONYMOUS mechanism may impose additional syntax on , e.g. it may say that the NUL, '@' and '\' characters are to be encoded as '\00', '\40' and '\5C' respectively in - thus allowing such tokens to encode all characters. -- Hallvard From owner-ietf-sasl Mon Dec 15 10:22:00 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFIM0ib010396 for ; Mon, 15 Dec 2003 10:22:00 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFIM07V010395 for ietf-sasl-bks; Mon, 15 Dec 2003 10:22:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (HOTASS-6.MIT.EDU [18.101.1.48]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFILxib010383 for ; Mon, 15 Dec 2003 10:21:59 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 66ED41515F2; Mon, 15 Dec 2003 13:22:00 -0500 (EST) To: Hallvard B Furuseth Cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: Moving to rfc2222bis last call References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> <3FDC8C1B.6070705@isode.com> From: Sam Hartman Date: Mon, 15 Dec 2003 13:22:00 -0500 In-Reply-To: (Hallvard B. Furuseth's message of "Mon, 15 Dec 2003 10:56:00 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Hallvard" == Hallvard B Furuseth writes: Hallvard> I can't offer any suggestions because I don't know what Hallvard> belongs there. I think what I'm really missing is a Hallvard> description of the purpose of the protocol profile. Hallvard> What will it be used for? What is it _not_ intended to Hallvard> be used for? Knowing that, the reader (and I) can judge Hallvard> for himself what should go in it, besides the mandatory Hallvard> items. Does anyone else feel this issue requires additional clarification? From owner-ietf-sasl Mon Dec 15 10:32:18 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFIWIib010978 for ; Mon, 15 Dec 2003 10:32:18 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFIWIIF010977 for ietf-sasl-bks; Mon, 15 Dec 2003 10:32:18 -0800 (PST) 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.10/8.12.8) with ESMTP id hBFIWHib010964 for ; Mon, 15 Dec 2003 10:32:17 -0800 (PST) (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 1AVxVv-0007c3-No; Mon, 15 Dec 2003 19:32:15 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.14) id 1AVxSW-0000us-NA; Mon, 15 Dec 2003 19:28:44 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AVxSW-0000H5-00; Mon, 15 Dec 2003 19:28:44 +0100 From: Hallvard B Furuseth Message-Id: To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: ANONYMOUS In-Reply-To: References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 15 Dec 2003 19:28:44 +0100 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=-4.9, required 12, BAYES_00 -4.90) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: >>>>>> "Hallvard" == Hallvard B Furuseth writes: > > Hallvard> What is needed is a > Hallvard> securicy consideration that ANONYMOUS must not (or MUST > Hallvard> NOT?) be enabled unless it is treated specially in this > Hallvard> respect. > > I think a SHOULD is sufficient. (...) OK. BTW, would it help to specify that ANONYMOUS gives the specified authentication ID, but a null authorization ID? -- Hallvard From owner-ietf-sasl Mon Dec 15 10:20:10 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFIKAib010243 for ; Mon, 15 Dec 2003 10:20:10 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFIKA4R010241 for ietf-sasl-bks; Mon, 15 Dec 2003 10:20:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (HOTASS-6.MIT.EDU [18.101.1.48]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFIK8ib010231 for ; Mon, 15 Dec 2003 10:20:09 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 20DA71515F2; Mon, 15 Dec 2003 13:20:08 -0500 (EST) To: Hallvard B Furuseth Cc: ietf-sasl@imc.org Subject: Re: ANONYMOUS References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> From: Sam Hartman Date: Mon, 15 Dec 2003 13:20:08 -0500 In-Reply-To: (Hallvard B. Furuseth's message of "Mon, 15 Dec 2003 12:03:13 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Hallvard" == Hallvard B Furuseth writes: Hallvard> [anon] section 4 (Security Considerations) says: >> The ANONYMOUS mechanism grants access to information by anyone. >> For this reason it should be disabled by default so the >> administrator can make an explicit decision to enable it. Hallvard> I disagree. I see no reason to disable ANONYMOUS as Hallvard> long as ANONYMOUS 'authentication' is treated as Hallvard> equivalent to no authentication rather than e.g. as Hallvard> authentication with a password. What is needed is a Hallvard> securicy consideration that ANONYMOUS must not (or MUST Hallvard> NOT?) be enabled unless it is treated specially in this Hallvard> respect. I think a SHOULD is sufficient. If your application/environment has well defined no authentication semantics, then you have a justification for violating the SHOULD. Write it up in your docs/specifications, explain what behavior you have and why you chose it and go on with life. From owner-ietf-sasl Mon Dec 15 11:13:15 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFJDFib013035 for ; Mon, 15 Dec 2003 11:13:15 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFJDFGF013034 for ietf-sasl-bks; Mon, 15 Dec 2003 11:13:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (HOTASS-6.MIT.EDU [18.101.1.48]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFJDEib013029 for ; Mon, 15 Dec 2003 11:13:14 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 93FDD1515F2; Mon, 15 Dec 2003 14:13:11 -0500 (EST) To: "Kurt D. Zeilenga" Cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: ANONYMOUS References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> <6.0.0.22.0.20031215110302.042ab1d0@127.0.0.1> From: Sam Hartman Date: Mon, 15 Dec 2003 14:13:11 -0500 In-Reply-To: <6.0.0.22.0.20031215110302.042ab1d0@127.0.0.1> (Kurt D. Zeilenga's message of "Mon, 15 Dec 2003 11:09:01 -0800") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> As this is a security consideration, not an implementation Kurt> imperative nor applicability statement, I believe 'should' Kurt> is more appropriate than 'SHOULD'. I don't much care but how is this particular security consideration not an implementation imperative justified for security reasons? From owner-ietf-sasl Mon Dec 15 11:09:28 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFJ9Sib012897 for ; Mon, 15 Dec 2003 11:09:28 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFJ9SxO012896 for ietf-sasl-bks; Mon, 15 Dec 2003 11:09:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFJ9Rib012891 for ; Mon, 15 Dec 2003 11:09:27 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.9) with ESMTP id hBFJ9Sa9061308; Mon, 15 Dec 2003 19:09:29 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031215110302.042ab1d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 15 Dec 2003 11:09:01 -0800 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: ANONYMOUS Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:20 AM 12/15/2003, Sam Hartman wrote: >>>>>> "Hallvard" == Hallvard B Furuseth writes: > > Hallvard> [anon] section 4 (Security Considerations) says: > > >> The ANONYMOUS mechanism grants access to information by anyone. > >> For this reason it should be disabled by default so the > >> administrator can make an explicit decision to enable it. > > Hallvard> I disagree. I see no reason to disable ANONYMOUS as > Hallvard> long as ANONYMOUS 'authentication' is treated as > Hallvard> equivalent to no authentication rather than e.g. as > Hallvard> authentication with a password. What is needed is a > Hallvard> securicy consideration that ANONYMOUS must not (or MUST > Hallvard> NOT?) be enabled unless it is treated specially in this > Hallvard> respect. > >I think a SHOULD is sufficient. If your application/environment has >well defined no authentication semantics, then you have a >justification for violating the SHOULD. Write it up in your >docs/specifications, explain what behavior you have and why you chose >it and go on with life. As this is a security consideration, not an implementation imperative nor applicability statement, I believe 'should' is more appropriate than 'SHOULD'. But same basic logic applies here. Implementors should consider the implications before enabling ANONYMOUS by default. From owner-ietf-sasl Mon Dec 15 11:41:18 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFJfIib014180 for ; Mon, 15 Dec 2003 11:41:18 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFJfIo0014179 for ietf-sasl-bks; Mon, 15 Dec 2003 11:41:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFJfHib014173 for ; Mon, 15 Dec 2003 11:41:17 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from CYRUS-TEST.andrew.cmu.edu (CYRUS-TEST.andrew.cmu.edu [128.2.10.171]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hBFJfIk5004012 for ; Mon, 15 Dec 2003 14:41:18 -0500 Date: Mon, 15 Dec 2003 14:41:17 -0500 (EST) From: Rob Siemborski To: ietf-sasl@imc.org Subject: Re: Moving to rfc2222bis last call In-Reply-To: <20031201174409.A27F91515F2@konishi-polis.mit.edu> Message-ID: References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 1 Dec 2003, Sam Hartman wrote: > What are we still waiting on before the next last call of this > document? I just noticed that the EXTERNAL mechanism doesn't have any limits on how big the client response can be. Are servers expected to handle responses of arbitrary length here, or can they get away with saying "we don't support authorization identifiers longer than x"? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Mon Dec 15 12:00:51 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFK0pib015210 for ; Mon, 15 Dec 2003 12:00:51 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFK0pHX015209 for ietf-sasl-bks; Mon, 15 Dec 2003 12:00:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFK0oib015203 for ; Mon, 15 Dec 2003 12:00:50 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.9) with ESMTP id hBFK0pa9061824; Mon, 15 Dec 2003 20:00:51 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031215114026.041860c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 15 Dec 2003 12:00:24 -0800 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: ANONYMOUS Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> <6.0.0.22.0.20031215110302.042ab1d0@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:13 AM 12/15/2003, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > > Kurt> As this is a security consideration, not an implementation > Kurt> imperative nor applicability statement, I believe 'should' > Kurt> is more appropriate than 'SHOULD'. > >I don't much care but how is this particular security consideration >not an implementation imperative justified for security reasons? My primary concern is not to give this 'should' special attention over the many other 'should' statements in the Security Considerations section AND not to litter the Security Considerations section with lots of SHOULDs. SHOULDs should be used sparingly. I think the current wording is fine. The section discusses security considerations. If, however, people think that we need to state specific implementation imperatives in this area, I suggest those be added to Section 1 and the Security Considerations section be left to just discussing considerations. Kurt From owner-ietf-sasl Mon Dec 15 12:12:36 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFKCaib015770 for ; Mon, 15 Dec 2003 12:12:36 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFKCa2Q015769 for ietf-sasl-bks; Mon, 15 Dec 2003 12:12:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFKCZib015764 for ; Mon, 15 Dec 2003 12:12:35 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.9) with ESMTP id hBFKCYa9061914; Mon, 15 Dec 2003 20:12:35 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031215120505.0419ac40@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 15 Dec 2003 12:12:08 -0800 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: Moving to rfc2222bis last call Cc: ietf-sasl@imc.org In-Reply-To: References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:41 AM 12/15/2003, Rob Siemborski wrote: >On Mon, 1 Dec 2003, Sam Hartman wrote: > >> What are we still waiting on before the next last call of this >> document? > >I just noticed that the EXTERNAL mechanism doesn't have any limits on how >big the client response can be. > >Are servers expected to handle responses of arbitrary length here, I assume they should be able to 'handle' (not choke) authzid of any length but can refuse to accept any authzid for any reason (including it just being unreasonably long). >or can >they get away with saying "we don't support authorization identifiers >longer than x"? They just generally should fail the exchange if the asserted authzid is too long (whatever that means to them). Of course, if the server believes the client to be rouge, it can (and likely should) just drop the protocol steam. I do not think we should impose any artificial limit here as reasonable lengths. Where absolutely needed, they should be stated in application-level profiles (as they own the form of the authzid). Kurt From owner-ietf-sasl Tue Dec 23 12:35:46 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNKZjib053926 for ; Tue, 23 Dec 2003 12:35:45 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBNKZjkP053925 for ietf-sasl-bks; Tue, 23 Dec 2003 12:35:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNKZiib053910 for ; Tue, 23 Dec 2003 12:35:45 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08146; Tue, 23 Dec 2003 15:35:44 -0500 (EST) Message-Id: <200312232035.PAA08146@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-04.txt Date: Tue, 23 Dec 2003 15:35:43 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-04.txt Pages : 11 Date : 2003-12-23 SASL provides a method for adding authentication support with an optional security layer to connection-based protocols. It also describes a structure for authentication mechanisms. The result is an abstraction layer between protocols and authentication mechanisms such that any SASL-compatible authentication mechanism can be used with any SASL-compatible protocol. This document describes how a SASL authentication mechanism is structured, how a protocol adds support for SASL, defines the protocol for carrying a security layer over a connection, and defines the EXTERNAL SASL authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2222bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-23153249.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-23153249.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Mon Dec 29 12:48:50 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTKmoib010713 for ; Mon, 29 Dec 2003 12:48:50 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBTKmoPv010712 for ietf-sasl-bks; Mon, 29 Dec 2003 12:48:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTKmkib010702 for ; Mon, 29 Dec 2003 12:48:48 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hBTKmKl4008794; Mon, 29 Dec 2003 15:48:20 -0500 Date: Mon, 29 Dec 2003 15:48:20 -0500 (EST) From: Rob Siemborski To: Internet-Drafts@ietf.org cc: ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-04.txt In-Reply-To: <200312232035.PAA08146@ietf.org> Message-ID: References: <200312232035.PAA08146@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: On Tue, 23 Dec 2003 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. > > Title : Simple Authentication and Security Layer (SASL) Nit: Document states that it will be a draft standard, is this still the case or is the stringprep stuff forcing us to recycle at proposed? I've sent additional editorial isses to Alexey, but nothing that should hold up the document. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-sasl Mon Dec 29 13:35:01 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTLZ1ib013905 for ; Mon, 29 Dec 2003 13:35:01 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBTLZ12T013904 for ietf-sasl-bks; Mon, 29 Dec 2003 13:35:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTLYwib013893 for ; Mon, 29 Dec 2003 13:35:00 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.9) with ESMTP id hBTLYwa9075518; Mon, 29 Dec 2003 21:34:58 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031229133042.02716f20@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 29 Dec 2003 13:34:47 -0800 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-04.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200312232035.PAA08146@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:48 PM 12/29/2003, Rob Siemborski wrote: >On Tue, 23 Dec 2003 Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. >> >> Title : Simple Authentication and Security Layer (SASL) > >Nit: Document states that it will be a draft standard, is this still the >case or is the stringprep stuff forcing us to recycle at proposed? We'll be recycling at Proposed. >I've sent additional editorial isses to Alexey, but nothing that should >hold up the document. Thanks, Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTLZ1ib013905 for ; Mon, 29 Dec 2003 13:35:01 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBTLZ12T013904 for ietf-sasl-bks; Mon, 29 Dec 2003 13:35:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTLYwib013893 for ; Mon, 29 Dec 2003 13:35:00 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.9) with ESMTP id hBTLYwa9075518; Mon, 29 Dec 2003 21:34:58 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031229133042.02716f20@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 29 Dec 2003 13:34:47 -0800 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-04.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200312232035.PAA08146@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:48 PM 12/29/2003, Rob Siemborski wrote: >On Tue, 23 Dec 2003 Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. >> >> Title : Simple Authentication and Security Layer (SASL) > >Nit: Document states that it will be a draft standard, is this still the >case or is the stringprep stuff forcing us to recycle at proposed? We'll be recycling at Proposed. >I've sent additional editorial isses to Alexey, but nothing that should >hold up the document. Thanks, Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTKmoib010713 for ; Mon, 29 Dec 2003 12:48:50 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBTKmoPv010712 for ietf-sasl-bks; Mon, 29 Dec 2003 12:48:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTKmkib010702 for ; Mon, 29 Dec 2003 12:48:48 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hBTKmKl4008794; Mon, 29 Dec 2003 15:48:20 -0500 Date: Mon, 29 Dec 2003 15:48:20 -0500 (EST) From: Rob Siemborski To: Internet-Drafts@ietf.org cc: ietf-sasl@imc.org Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-04.txt In-Reply-To: <200312232035.PAA08146@ietf.org> Message-ID: References: <200312232035.PAA08146@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: On Tue, 23 Dec 2003 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. > > Title : Simple Authentication and Security Layer (SASL) Nit: Document states that it will be a draft standard, is this still the case or is the stringprep stuff forcing us to recycle at proposed? I've sent additional editorial isses to Alexey, but nothing that should hold up the document. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNKZjib053926 for ; Tue, 23 Dec 2003 12:35:45 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBNKZjkP053925 for ietf-sasl-bks; Tue, 23 Dec 2003 12:35:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNKZiib053910 for ; Tue, 23 Dec 2003 12:35:45 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08146; Tue, 23 Dec 2003 15:35:44 -0500 (EST) Message-Id: <200312232035.PAA08146@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-04.txt Date: Tue, 23 Dec 2003 15:35:43 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-04.txt Pages : 11 Date : 2003-12-23 SASL provides a method for adding authentication support with an optional security layer to connection-based protocols. It also describes a structure for authentication mechanisms. The result is an abstraction layer between protocols and authentication mechanisms such that any SASL-compatible authentication mechanism can be used with any SASL-compatible protocol. This document describes how a SASL authentication mechanism is structured, how a protocol adds support for SASL, defines the protocol for carrying a security layer over a connection, and defines the EXTERNAL SASL authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2222bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-23153249.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-23153249.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFKCaib015770 for ; Mon, 15 Dec 2003 12:12:36 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFKCa2Q015769 for ietf-sasl-bks; Mon, 15 Dec 2003 12:12:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFKCZib015764 for ; Mon, 15 Dec 2003 12:12:35 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.9) with ESMTP id hBFKCYa9061914; Mon, 15 Dec 2003 20:12:35 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031215120505.0419ac40@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 15 Dec 2003 12:12:08 -0800 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: Moving to rfc2222bis last call Cc: ietf-sasl@imc.org In-Reply-To: References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:41 AM 12/15/2003, Rob Siemborski wrote: >On Mon, 1 Dec 2003, Sam Hartman wrote: > >> What are we still waiting on before the next last call of this >> document? > >I just noticed that the EXTERNAL mechanism doesn't have any limits on how >big the client response can be. > >Are servers expected to handle responses of arbitrary length here, I assume they should be able to 'handle' (not choke) authzid of any length but can refuse to accept any authzid for any reason (including it just being unreasonably long). >or can >they get away with saying "we don't support authorization identifiers >longer than x"? They just generally should fail the exchange if the asserted authzid is too long (whatever that means to them). Of course, if the server believes the client to be rouge, it can (and likely should) just drop the protocol steam. I do not think we should impose any artificial limit here as reasonable lengths. Where absolutely needed, they should be stated in application-level profiles (as they own the form of the authzid). Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFK0pib015210 for ; Mon, 15 Dec 2003 12:00:51 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFK0pHX015209 for ietf-sasl-bks; Mon, 15 Dec 2003 12:00:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFK0oib015203 for ; Mon, 15 Dec 2003 12:00:50 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.9) with ESMTP id hBFK0pa9061824; Mon, 15 Dec 2003 20:00:51 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031215114026.041860c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 15 Dec 2003 12:00:24 -0800 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: ANONYMOUS Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> <6.0.0.22.0.20031215110302.042ab1d0@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:13 AM 12/15/2003, Sam Hartman wrote: >>>>>> "Kurt" == Kurt D Zeilenga writes: > > > Kurt> As this is a security consideration, not an implementation > Kurt> imperative nor applicability statement, I believe 'should' > Kurt> is more appropriate than 'SHOULD'. > >I don't much care but how is this particular security consideration >not an implementation imperative justified for security reasons? My primary concern is not to give this 'should' special attention over the many other 'should' statements in the Security Considerations section AND not to litter the Security Considerations section with lots of SHOULDs. SHOULDs should be used sparingly. I think the current wording is fine. The section discusses security considerations. If, however, people think that we need to state specific implementation imperatives in this area, I suggest those be added to Section 1 and the Security Considerations section be left to just discussing considerations. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFJfIib014180 for ; Mon, 15 Dec 2003 11:41:18 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFJfIo0014179 for ietf-sasl-bks; Mon, 15 Dec 2003 11:41:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFJfHib014173 for ; Mon, 15 Dec 2003 11:41:17 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from CYRUS-TEST.andrew.cmu.edu (CYRUS-TEST.andrew.cmu.edu [128.2.10.171]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hBFJfIk5004012 for ; Mon, 15 Dec 2003 14:41:18 -0500 Date: Mon, 15 Dec 2003 14:41:17 -0500 (EST) From: Rob Siemborski To: ietf-sasl@imc.org Subject: Re: Moving to rfc2222bis last call In-Reply-To: <20031201174409.A27F91515F2@konishi-polis.mit.edu> Message-ID: References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 1 Dec 2003, Sam Hartman wrote: > What are we still waiting on before the next last call of this > document? I just noticed that the EXTERNAL mechanism doesn't have any limits on how big the client response can be. Are servers expected to handle responses of arbitrary length here, or can they get away with saying "we don't support authorization identifiers longer than x"? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFJDFib013035 for ; Mon, 15 Dec 2003 11:13:15 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFJDFGF013034 for ietf-sasl-bks; Mon, 15 Dec 2003 11:13:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (HOTASS-6.MIT.EDU [18.101.1.48]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFJDEib013029 for ; Mon, 15 Dec 2003 11:13:14 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 93FDD1515F2; Mon, 15 Dec 2003 14:13:11 -0500 (EST) To: "Kurt D. Zeilenga" Cc: Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: ANONYMOUS References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> <6.0.0.22.0.20031215110302.042ab1d0@127.0.0.1> From: Sam Hartman Date: Mon, 15 Dec 2003 14:13:11 -0500 In-Reply-To: <6.0.0.22.0.20031215110302.042ab1d0@127.0.0.1> (Kurt D. Zeilenga's message of "Mon, 15 Dec 2003 11:09:01 -0800") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> As this is a security consideration, not an implementation Kurt> imperative nor applicability statement, I believe 'should' Kurt> is more appropriate than 'SHOULD'. I don't much care but how is this particular security consideration not an implementation imperative justified for security reasons? Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFJ9Sib012897 for ; Mon, 15 Dec 2003 11:09:28 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFJ9SxO012896 for ietf-sasl-bks; Mon, 15 Dec 2003 11:09:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFJ9Rib012891 for ; Mon, 15 Dec 2003 11:09:27 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.9) with ESMTP id hBFJ9Sa9061308; Mon, 15 Dec 2003 19:09:29 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031215110302.042ab1d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 15 Dec 2003 11:09:01 -0800 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: ANONYMOUS Cc: Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:20 AM 12/15/2003, Sam Hartman wrote: >>>>>> "Hallvard" == Hallvard B Furuseth writes: > > Hallvard> [anon] section 4 (Security Considerations) says: > > >> The ANONYMOUS mechanism grants access to information by anyone. > >> For this reason it should be disabled by default so the > >> administrator can make an explicit decision to enable it. > > Hallvard> I disagree. I see no reason to disable ANONYMOUS as > Hallvard> long as ANONYMOUS 'authentication' is treated as > Hallvard> equivalent to no authentication rather than e.g. as > Hallvard> authentication with a password. What is needed is a > Hallvard> securicy consideration that ANONYMOUS must not (or MUST > Hallvard> NOT?) be enabled unless it is treated specially in this > Hallvard> respect. > >I think a SHOULD is sufficient. If your application/environment has >well defined no authentication semantics, then you have a >justification for violating the SHOULD. Write it up in your >docs/specifications, explain what behavior you have and why you chose >it and go on with life. As this is a security consideration, not an implementation imperative nor applicability statement, I believe 'should' is more appropriate than 'SHOULD'. But same basic logic applies here. Implementors should consider the implications before enabling ANONYMOUS by default. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFIWIib010978 for ; Mon, 15 Dec 2003 10:32:18 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFIWIIF010977 for ietf-sasl-bks; Mon, 15 Dec 2003 10:32:18 -0800 (PST) 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.10/8.12.8) with ESMTP id hBFIWHib010964 for ; Mon, 15 Dec 2003 10:32:17 -0800 (PST) (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 1AVxVv-0007c3-No; Mon, 15 Dec 2003 19:32:15 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.14) id 1AVxSW-0000us-NA; Mon, 15 Dec 2003 19:28:44 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AVxSW-0000H5-00; Mon, 15 Dec 2003 19:28:44 +0100 From: Hallvard B Furuseth Message-Id: To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: ANONYMOUS In-Reply-To: References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 15 Dec 2003 19:28:44 +0100 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=-4.9, required 12, BAYES_00 -4.90) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: >>>>>> "Hallvard" == Hallvard B Furuseth writes: > > Hallvard> What is needed is a > Hallvard> securicy consideration that ANONYMOUS must not (or MUST > Hallvard> NOT?) be enabled unless it is treated specially in this > Hallvard> respect. > > I think a SHOULD is sufficient. (...) OK. BTW, would it help to specify that ANONYMOUS gives the specified authentication ID, but a null authorization ID? -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFIM0ib010396 for ; Mon, 15 Dec 2003 10:22:00 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFIM07V010395 for ietf-sasl-bks; Mon, 15 Dec 2003 10:22:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (HOTASS-6.MIT.EDU [18.101.1.48]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFILxib010383 for ; Mon, 15 Dec 2003 10:21:59 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 66ED41515F2; Mon, 15 Dec 2003 13:22:00 -0500 (EST) To: Hallvard B Furuseth Cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: Moving to rfc2222bis last call References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> <3FDC8C1B.6070705@isode.com> From: Sam Hartman Date: Mon, 15 Dec 2003 13:22:00 -0500 In-Reply-To: (Hallvard B. Furuseth's message of "Mon, 15 Dec 2003 10:56:00 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Hallvard" == Hallvard B Furuseth writes: Hallvard> I can't offer any suggestions because I don't know what Hallvard> belongs there. I think what I'm really missing is a Hallvard> description of the purpose of the protocol profile. Hallvard> What will it be used for? What is it _not_ intended to Hallvard> be used for? Knowing that, the reader (and I) can judge Hallvard> for himself what should go in it, besides the mandatory Hallvard> items. Does anyone else feel this issue requires additional clarification? Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFIKAib010243 for ; Mon, 15 Dec 2003 10:20:10 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFIKA4R010241 for ietf-sasl-bks; Mon, 15 Dec 2003 10:20:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (HOTASS-6.MIT.EDU [18.101.1.48]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFIK8ib010231 for ; Mon, 15 Dec 2003 10:20:09 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 20DA71515F2; Mon, 15 Dec 2003 13:20:08 -0500 (EST) To: Hallvard B Furuseth Cc: ietf-sasl@imc.org Subject: Re: ANONYMOUS References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> From: Sam Hartman Date: Mon, 15 Dec 2003 13:20:08 -0500 In-Reply-To: (Hallvard B. Furuseth's message of "Mon, 15 Dec 2003 12:03:13 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Hallvard" == Hallvard B Furuseth writes: Hallvard> [anon] section 4 (Security Considerations) says: >> The ANONYMOUS mechanism grants access to information by anyone. >> For this reason it should be disabled by default so the >> administrator can make an explicit decision to enable it. Hallvard> I disagree. I see no reason to disable ANONYMOUS as Hallvard> long as ANONYMOUS 'authentication' is treated as Hallvard> equivalent to no authentication rather than e.g. as Hallvard> authentication with a password. What is needed is a Hallvard> securicy consideration that ANONYMOUS must not (or MUST Hallvard> NOT?) be enabled unless it is treated specially in this Hallvard> respect. I think a SHOULD is sufficient. If your application/environment has well defined no authentication semantics, then you have a justification for violating the SHOULD. Write it up in your docs/specifications, explain what behavior you have and why you chose it and go on with life. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFB3Rib089148 for ; Mon, 15 Dec 2003 03:03:27 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFB3RoW089147 for ietf-sasl-bks; Mon, 15 Dec 2003 03:03:27 -0800 (PST) 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.10/8.12.8) with ESMTP id hBFB3Pib089112 for ; Mon, 15 Dec 2003 03:03:25 -0800 (PST) (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 1AVqVW-0000MH-RY for ietf-sasl@imc.org; Mon, 15 Dec 2003 12:03:22 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AVqVN-0006ez-Kf for ietf-sasl@imc.org; Mon, 15 Dec 2003 12:03:13 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AVqVN-0006y4-00 for ietf-sasl@imc.org; Mon, 15 Dec 2003 12:03:13 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-sasl@imc.org Subject: ANONYMOUS In-Reply-To: References: <6.0.0.22.0.20031105173306.048bc888@127.0.0.1> <3FAA293C.1000206@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 15 Dec 2003 12:03:13 +0100 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=-4.9, required 12, BAYES_00 -4.90) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [anon] section 4 (Security Considerations) says: > The ANONYMOUS mechanism grants access to information by anyone. For > this reason it should be disabled by default so the administrator can > make an explicit decision to enable it. I disagree. I see no reason to disable ANONYMOUS as long as ANONYMOUS 'authentication' is treated as equivalent to no authentication rather than e.g. as authentication with a password. What is needed is a securicy consideration that ANONYMOUS must not (or MUST NOT?) be enabled unless it is treated specially in this respect. If anon is treated as no auth, some other security considerations disappear too, since they are no different from if the user did not authenticate: > If the anonymous user has any write privileges, a denial of service > attack is possible by filling up all available space. This can be > prevented by disabling all write access by anonymous users. > If anonymous users have read and write access to the same area, the > server can be used as a communication mechanism to anonymously > exchange information. (...) > If the anonymous user can run many expensive operations (e.g., an IMAP > SEARCH BODY command), this could enable a denial of service attack. > While servers may impose a limit on the number of anonymous users, it > is noted that such limits enable denial of service attacks and should > be used with caution. Also, > Anonymous connections are susceptible to man in the middle attacks > which view or alter the data transferred. Clients and servers are > encouraged to support external integrity and encryption mechanisms. It's not that the connection is anonymous which makes it suspectible, but that [anon] provides no SASL security layer. Also, in an earlier thread, I wrote: >Alexey Melnikov writes: >>Kurt D. Zeilenga wrote: >>>At 04:45 PM 11/5/2003, Hallvard B Furuseth wrote: >>> >>>> Looking over the various SASL drafts, I miss one piece of functionality: >>>> To authenticate anonymously, removing any SASL layer, but still >>>> providing an unauthenticated ID (e.g. for logging purposes). >>>> >> How is this different from ANONYMOUS (except for @ sign requirement). > > That's the difference. If there is nothing special about the '@' > character in the underlying auth IDs, then the exclusion of names with > '@' in them is unnatural. Though one could of course introduce a > private hack like using \ for a quote character and type @ as \40, or > something. That reminds me: Would it be appropriate to put something like this in [anon]? A protocol using the ANONYMOUS mechanism may impose additional syntax on , e.g. it may say that the NUL, '@' and '\' characters are to be encoded as '\00', '\40' and '\5C' respectively in - thus allowing such tokens to encode all characters. -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBF9uBib081505 for ; Mon, 15 Dec 2003 01:56:11 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBF9uBIe081504 for ietf-sasl-bks; Mon, 15 Dec 2003 01:56:11 -0800 (PST) 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.10/8.12.8) with ESMTP id hBF9u4ib081451 for ; Mon, 15 Dec 2003 01:56:05 -0800 (PST) (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 1AVpSL-0005vd-Lj; Mon, 15 Dec 2003 10:56:01 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.14) id 1AVpSK-0000iZ-H1; Mon, 15 Dec 2003 10:56:00 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AVpSK-0006nn-00; Mon, 15 Dec 2003 10:56:00 +0100 From: Hallvard B Furuseth Message-Id: To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Moving to rfc2222bis last call In-Reply-To: <3FDC8C1B.6070705@isode.com> References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> <3FDC8C1B.6070705@isode.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 15 Dec 2003 10:56:00 +0100 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=-4.9, required 12, BAYES_00 -4.90) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >> Subject: Re: rfc2222bis: protocol profile? >> From: Hallvard B Furuseth >> Date: Mon, 10 Nov 2003 08:10:22 +0100 >> Message-Id: >> URL: http://www.imc.org/ietf-sasl/mail-archive/msg01304.html >> >> What belongs in the protocol profile? > > I will ignore this one, unless you have a specific suggestion/text. > I am not sure I can give you a generic future proof advice. I can't offer any suggestions because I don't know what belongs there. I think what I'm really missing is a description of the purpose of the protocol profile. What will it be used for? What is it _not_ intended to be used for? Knowing that, the reader (and I) can judge for himself what should go in it, besides the mandatory items. >> The 'selects no security layer' thread. I've lost track of this one and >> will have to reread it. But originally all I wanted was to clarify that >> specific phrase: either to 'does not select a security layer' or >> 'selects that there shall be no security layer', or whatever else is >> meant. That has not been done yet. > > I think I've addressed the particular issue by saying that mechanism > that are incapable of negotiating a security layer always select "no layer". OK, if the quotes are in place, or otherwise the new wording can't be interpreted as "doesn't select a (new) layer". -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBEH2Aib075484 for ; Sun, 14 Dec 2003 09:02:10 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBEH2Aqf075483 for ietf-sasl-bks; Sun, 14 Dec 2003 09:02:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBEH1wib075470 for ; Sun, 14 Dec 2003 09:02:07 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust128.tnt110.lnd4.gbr.da.uu.net [62.188.174.128]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 14 Dec 2003 17:06:15 +0000 Message-ID: <3FDC8C1B.6070705@isode.com> Date: Sun, 14 Dec 2003 16:13:15 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth CC: ietf-sasl@imc.org Subject: Re: Moving to rfc2222bis last call References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallvard B Furuseth wrote: >Sam Hartman writes: > > >>What are we still waiting on before the next last call of this >>document? >> >> > >I think this document needs another version before it is ready for last >call. Here is the unfinished business I'm aware of: > >------------------------------------------------------------------------ > >The 'suggested text about multiple SASL mechanisms' thread. > > I think this is done. >------------------------------------------------------------------------ > >Subject: Re: rfc2222bis: protocol profile? >From: Hallvard B Furuseth >Date: Mon, 10 Nov 2003 08:10:22 +0100 >Message-Id: >URL: http://www.imc.org/ietf-sasl/mail-archive/msg01304.html > >What belongs in the protocol profile? > > I will ignore this one, unless you have a specific suggestion/text. I am not sure I can give you a generic future proof advice. >------------------------------------------------------------------------ > >Subject: draft-ietf-sasl-rfc2222bis-02.txt section 4.2 >From: Tony Hansen >Date: Thu, 06 Nov 2003 12:02:22 -0500 >Message-ID: <3FAA7E9E.3080704@att.com> >URL: http://www.imc.org/ietf-sasl/mail-archive/msg01278.html > >Split section 4.2 (Authorization identities and proxy authentication). >It appears to be mixing two totally different discussions together in a >slightly confusing mess. > This is done. I had to merge my recent changes with the proposed text. >------------------------------------------------------------------------ > >The 'selects no security layer' thread. I've lost track of this one and >will have to reread it. But originally all I wanted was to clarify that >specific phrase: either to 'does not select a security layer' or >'selects that there shall be no security layer', or whatever else is >meant. That has not been done yet. > > I think I've addressed the particular issue by saying that mechanism that are incapable of negotiating a security layer always select "no layer". Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB85jlib098527 for ; Sun, 7 Dec 2003 21:45:47 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB85jlXm098526 for ietf-sasl-bks; Sun, 7 Dec 2003 21:45:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mariner.pc.cs.cmu.edu (dsl093-061-085.pit1.dsl.speakeasy.net [66.93.61.85]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB85jfib098482 for ; Sun, 7 Dec 2003 21:45:43 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa04100; 8 Dec 2003 0:45 EST Date: Mon, 08 Dec 2003 00:44:59 -0500 From: Jeffrey Hutzelman To: Simon Josefsson cc: Jeffrey Hutzelman , Sam Hartman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt Message-ID: <3750000.1070862299@mariner.pc.cs.cmu.edu> In-Reply-To: References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> <58040000.1070494633@minbar.fac.cs.cmu.edu> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sunday, December 07, 2003 05:30:47 +0100 Simon Josefsson wrote: > Jeffrey Hutzelman writes: > >> On Wednesday, December 03, 2003 19:56:03 +0100 Simon Josefsson >> wrote: >> >>> I don't see a conflict with this and the text I proposed, but I'm not >>> sure if you argue for or against the text. In fact, the problem of >>> forward compatible databases was the motivation for my text. The text >>> would help if SASLPrepX(SASLPrep(string)) != SASLPrepX(string) where >>> SASLPrepX is any future revision of SASLPrep. >> >> Yeah; that's supposed to be a guarantee. Part of this is spelled out >> in RFC2454, at the end of section 3 and in section 7.1: >> >> Authors of profiles of this document need to consider the effects of >> changing the mapping of any currently-assigned character when >> updating their profiles. Adding a new mapping for a currently- >> assigned character, or changing an existing mapping, could cause a >> variance between the behavior of systems that have been updated and >> systems that have not been updated. > > This is not much of a guarantee. To me, the wording suggest that > stringprep profiles actually can be backwards incompatible, if the > designers feel the benefits outweigh the costs that are mentioned. Yes, I believe that's exactly what it says. It may not seem like much of a guarantee, but it's the best we can possibly have. Designers of future versions of a profile will always be able to break backward compatibility, no matter what we do -- no "requirement" we write now can be effective against an IETF concensus in the future. >> A subsequent version of a profile that references a newer version of >> a repertoire with new code points will inherently have some code >> points move from category U to either D, MN, or AO. For backwards >> compatibility, a subsequent version of a profile MUST NOT move code >> points from any other category. That is, current AO, MN, or D code >> points MUST NOT ever change to a different category. > > This is good text, and I thought it would take of this problem. > However, it doesn't appear to be that simple, because it continue to > say: > > Applications creating queries MUST treat U code points as if they > were AO when preparing the query to be entered in the process > described by a profile of stringprep. Those applications MAY > optionally have a preprocessor that provide stricter checks: treating > unassigned code points in the input as errors, or warning the user > about the fact that the code point is unassigned in the version of a > profile that the software is based on; such a choice is a local > matter for the software. > > So the result is that if the profile is used with AllowUnassigned set > to true, the computed strings are not necessarily forwards compatible. That is correct - if you apply stringprep with AllowUnassigned set to TRUE, there is no guarantee that two implementations will produce the same result given the same input. But that's OK for a query string that's going to be used "once", right now -- the worst thing that can happen is that it doesn't match when it "should". However, for a string that's going to be stored long-term, preparing it incorrectly now is fatal; it will then _NEVER_ match a correctly prepared string. If there are unassigned code points, then you can't know if you're preparing it correctly; the easiest solution to this problem is to raise an exception now, and refuse to store a string if you don't know how to prepare it correctly. That's what setting AllowUnassigned to FALSE does. So I'll go back to my original statement -- IF a server is going to prepare strings in advance (which it cannot avoid if it's going to precompute a partial MD5 context), then it MUST set AllowUnassigned to FALSE and reject strings which contain unassigned code points. > Furthermore, one of the three ways forward presented in > draft-faltstrom-unicode-synchronisation-00, to support new Unicode > versions, include breaking backwards compatibility in stringprep > profiles. I've not had a chance to read that document yet, so I can't comment on it. > To summarize, I don't believe the SASLPrep2(SASLPrep1(string)) == > SASLPrep2(string) guarantee hold universally, nor follow from the core > document. > > This problem can be solved by adding a discussion in the SASLPrep > document that contain some guarantee that will hold for future > versions of the SASLPrep profile. Perhaps even explicitly mention > which path in draft-faltstrom-unicode-synchronisation-00 SASLPrep will > follow. We can't make an effective guarantee against a future IETF concensus. But given the text in RFC2454, I do agree we need to address the issue, and express the intent that the mappings of code points not in class U will not change in future versions of the specification. > Alternatively, you could recommend applications to store the > unprepared original passwords, which will be safe regardless of what > SASLPrep will behave in the future. I prefer this approach, but > judging from the responses to my proposed text for CRAM-MD5, perhaps > there isn't consensus about that. I get the impression that people like the idea of storing a partial MD5 context, even though doing so doesn't offer much protection. If servers are going to do this, I think they should be REQUIRED to prepare with AllowUnassigned set FALSE. OTOH, if they're going to store passwords, I agree that storing unprepared passwords allows for the greatest chance of future interoperability. > Finally, each mechanism using SASLPrep should also say when and how > AllowUnassigned is set. Absolutely. -- Jeff Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB74VZib022099 for ; Sat, 6 Dec 2003 20:31:35 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB74VZNh022098 for ietf-sasl-bks; Sat, 6 Dec 2003 20:31:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB74VPib022089 for ; Sat, 6 Dec 2003 20:31:32 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.10/8.12.10) with ESMTP id hB74V6AU007454 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 7 Dec 2003 05:31:11 +0100 To: Jeffrey Hutzelman Cc: Sam Hartman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> <58040000.1070494633@minbar.fac.cs.cmu.edu> From: Simon Josefsson X-Payment: hashcash 1.2 0:031207:jhutz@cmu.edu:3158a3f29a2de7ad X-Hashcash: 0:031207:jhutz@cmu.edu:3158a3f29a2de7ad X-Payment: hashcash 1.2 0:031207:hartmans@mit.edu:9a7fb563e1dda382 X-Hashcash: 0:031207:hartmans@mit.edu:9a7fb563e1dda382 X-Payment: hashcash 1.2 0:031207:ietf-sasl@imc.org:22c45d20771641d2 X-Hashcash: 0:031207:ietf-sasl@imc.org:22c45d20771641d2 Date: Sun, 07 Dec 2003 05:30:47 +0100 In-Reply-To: <58040000.1070494633@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Wed, 03 Dec 2003 18:37:13 -0500") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeffrey Hutzelman writes: > On Wednesday, December 03, 2003 19:56:03 +0100 Simon Josefsson > wrote: > >> I don't see a conflict with this and the text I proposed, but I'm not >> sure if you argue for or against the text. In fact, the problem of >> forward compatible databases was the motivation for my text. The text >> would help if SASLPrepX(SASLPrep(string)) != SASLPrepX(string) where >> SASLPrepX is any future revision of SASLPrep. > > Yeah; that's supposed to be a guarantee. Part of this is spelled out > in RFC2454, at the end of section 3 and in section 7.1: > > Authors of profiles of this document need to consider the effects of > changing the mapping of any currently-assigned character when > updating their profiles. Adding a new mapping for a currently- > assigned character, or changing an existing mapping, could cause a > variance between the behavior of systems that have been updated and > systems that have not been updated. This is not much of a guarantee. To me, the wording suggest that stringprep profiles actually can be backwards incompatible, if the designers feel the benefits outweigh the costs that are mentioned. > A subsequent version of a profile that references a newer version of > a repertoire with new code points will inherently have some code > points move from category U to either D, MN, or AO. For backwards > compatibility, a subsequent version of a profile MUST NOT move code > points from any other category. That is, current AO, MN, or D code > points MUST NOT ever change to a different category. This is good text, and I thought it would take of this problem. However, it doesn't appear to be that simple, because it continue to say: Applications creating queries MUST treat U code points as if they were AO when preparing the query to be entered in the process described by a profile of stringprep. Those applications MAY optionally have a preprocessor that provide stricter checks: treating unassigned code points in the input as errors, or warning the user about the fact that the code point is unassigned in the version of a profile that the software is based on; such a choice is a local matter for the software. So the result is that if the profile is used with AllowUnassigned set to true, the computed strings are not necessarily forwards compatible. Furthermore, one of the three ways forward presented in draft-faltstrom-unicode-synchronisation-00, to support new Unicode versions, include breaking backwards compatibility in stringprep profiles. To summarize, I don't believe the SASLPrep2(SASLPrep1(string)) == SASLPrep2(string) guarantee hold universally, nor follow from the core document. This problem can be solved by adding a discussion in the SASLPrep document that contain some guarantee that will hold for future versions of the SASLPrep profile. Perhaps even explicitly mention which path in draft-faltstrom-unicode-synchronisation-00 SASLPrep will follow. Alternatively, you could recommend applications to store the unprepared original passwords, which will be safe regardless of what SASLPrep will behave in the future. I prefer this approach, but judging from the responses to my proposed text for CRAM-MD5, perhaps there isn't consensus about that. Finally, each mechanism using SASLPrep should also say when and how AllowUnassigned is set. Thanks, Simon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB65AJib091480 for ; Fri, 5 Dec 2003 21:10:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB65AJDJ091479 for ietf-sasl-bks; Fri, 5 Dec 2003 21:10:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB65AIib091474 for ; Fri, 5 Dec 2003 21:10:18 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.9) with ESMTP id hB65ALa9025553; Sat, 6 Dec 2003 05:10:21 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031205210329.026fd4f0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 05 Dec 2003 21:09:20 -0800 To: "Sebastian Petrescu" From: "Kurt D. Zeilenga" Subject: Re: sasl + pam : ietf-sasl Cc: ietf-sasl@imc.org In-Reply-To: <6.0.0.22.0.20031205203112.027483c8@127.0.0.1> References: <6.0.0.22.0.20031205203112.027483c8@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: Sebastian, Your post is off-topic. This list is reserved for discussions related to the standardization of SASL. Your post would more appropriately be directed to list specific to the software you are using. It appears you are using Cyrus SASL, hence I suggest you direct your enquiry to lists.andrew.cmu.edu>. Kurt, IETF SASL WG Co-chair At 08:32 PM 12/5/2003, Sebastian Petrescu wrote: > Hello. > I do have a problem. I'm trying to install postfix + sasl with pam support. >saslauthd -v >saslauthd 2.1.17 >authentication mechanisms: getpwent rimap shadow > >I do have pam installed on my system .. and I'v vonfigured sasl: >./configure --prefix=3D/usr --enable-anon --enable-plain --enable-login --disable-krb4 --with-pam --with-saslauthd=3D/var/run/saslauthd = >--with-plugindir=3D/usr/lib/sasl2 --libdir=3D/usr/lib/sasl2 = >--with-plugindir=3D/usr/lib/sasl2 |grep pam > >configure: WARNING: Disabling GSSAPI - no include files found >configure: running /bin/sh './configure' --prefix=3D/usr/local '--enable-anon' '--enable-plain' '--enable-login' '--disable-krb4' '--with-saslauthd=3D/var/run/saslauthd' '--libdir=3D/usr/lib/sasl2' '--with-plugindir=3D/usr/lib/sasl2' '--with-pam=3D/lib/security' --cache-file=3D.././config.cache --srcdir=3D. >configure: WARNING: Disabling GSSAPI - no include files found >checking for pam_start in -lpam... (cached) no > > >I do have pam installed.. I have recompiled pam and installed latest libraries. > > Can someone please give me a hint ? Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB64Xhib089893 for ; Fri, 5 Dec 2003 20:33:43 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB64XhE5089892 for ietf-sasl-bks; Fri, 5 Dec 2003 20:33:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB64Xfib089887 for ; Fri, 5 Dec 2003 20:33:41 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.9) with ESMTP id hB64Xia9025211 for ; Sat, 6 Dec 2003 04:33:44 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031205203112.027483c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 05 Dec 2003 20:32:43 -0800 To: ietf-sasl@imc.org From: "Sebastian Petrescu" Subject: sasl + pam : ietf-sasl 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: Hello. I do have a problem. I'm trying to install postfix + sasl with pam support. saslauthd -v saslauthd 2.1.17 authentication mechanisms: getpwent rimap shadow I do have pam installed on my system .. and I'v vonfigured sasl: ./configure --prefix=3D/usr --enable-anon --enable-plain --enable-login --disable-krb4 --with-pam --with-saslauthd=3D/var/run/saslauthd = --with-plugindir=3D/usr/lib/sasl2 --libdir=3D/usr/lib/sasl2 = --with-plugindir=3D/usr/lib/sasl2 |grep pam configure: WARNING: Disabling GSSAPI - no include files found configure: running /bin/sh './configure' --prefix=3D/usr/local '--enable-anon' '--enable-plain' '--enable-login' '--disable-krb4' '--with-saslauthd=3D/var/run/saslauthd' '--libdir=3D/usr/lib/sasl2' '--with-plugindir=3D/usr/lib/sasl2' '--with-pam=3D/lib/security' --cache-file=3D.././config.cache --srcdir=3D. configure: WARNING: Disabling GSSAPI - no include files found checking for pam_start in -lpam... (cached) no I do have pam installed.. I have recompiled pam and installed latest libraries. Can someone please give me a hint ? Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5GEjib050166 for ; Fri, 5 Dec 2003 08:14:45 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5GEjER050165 for ietf-sasl-bks; Fri, 5 Dec 2003 08:14:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-NINETEEN.MIT.EDU [18.187.5.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5GEhib050158 for ; Fri, 5 Dec 2003 08:14:43 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 15DA71515F2; Fri, 5 Dec 2003 11:14:38 -0500 (EST) To: Lyndon Nerenberg Cc: "Kurt D. Zeilenga" , Simon Josefsson , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> <6.0.0.22.0.20031203123841.02784828@127.0.0.1> <2147483647.1070564839@[192.168.42.6]> From: Sam Hartman Date: Fri, 05 Dec 2003 11:14:38 -0500 In-Reply-To: <2147483647.1070564839@[192.168.42.6]> (Lyndon Nerenberg's message of "Thu, 04 Dec 2003 19:07:19 -0800") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Lyndon" == Lyndon Nerenberg writes: Lyndon> I'm having no luck coming up with text that explains this Lyndon> clearly. And I'm still not convinced that this should be Lyndon> discussed in the mechanism spec, since it applies much Lyndon> more widely than just CRAM. 2222bis seems to me to be a Lyndon> better place to lay this out. I disagree. How to prepare authentication identities is entirely a mechanism matter. The base spec can point out the general concern but cannot constrain what the mechanism does. For example various GSSAPI mechanisms may do much more complicated stringprep. Kerberos certainly will. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5CJZib037545 for ; Fri, 5 Dec 2003 04:19:35 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5CJYWv037544 for ietf-sasl-bks; Fri, 5 Dec 2003 04:19:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5CJSib037537 for ; Fri, 5 Dec 2003 04:19:34 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.253]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Fri, 5 Dec 2003 12:23:00 +0000 Message-ID: <3FD077CB.9090101@isode.com> Date: Fri, 05 Dec 2003 12:19:23 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Moving to rfc2222bis last call References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> In-Reply-To: <20031201174409.A27F91515F2@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: >What are we still waiting on before the next last call of this >document? > Rob's assessment is right. I also need to work on some issues raised by Hallvard. I am a bit busy at the moment. I will try to push a new revision in a week or so. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB537Xib040211 for ; Thu, 4 Dec 2003 19:07:33 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB537XJX040210 for ietf-sasl-bks; Thu, 4 Dec 2003 19:07:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB537Tib040204 for ; Thu, 4 Dec 2003 19:07:31 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from [192.168.1.102] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id hB537M40007527; Thu, 4 Dec 2003 20:07:23 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Thu, 04 Dec 2003 19:07:19 -0800 From: Lyndon Nerenberg To: "Kurt D. Zeilenga" , Simon Josefsson cc: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt Message-ID: <2147483647.1070564839@[192.168.42.6]> In-Reply-To: <6.0.0.22.0.20031203123841.02784828@127.0.0.1> References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> <6.0.0.22.0.20031203123841.02784828@127.0.0.1> X-Mailer: Mulberry/3.1.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on orthanc.ca Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Wednesday, December 3, 2003 1:05 PM -0800 "Kurt D. Zeilenga" wrote: > The client copy of the user name and shared secret should > be defined as query strings and, hence, unassigned code points > are allowed to appear in the prepared output. The server > copy of the user name and shared secret should be viewed > as stored strings and, hence, unassigned code points are not > allowed to appear in the prepared output. > > The draft needs to be revised to make this clear. I'm having no luck coming up with text that explains this clearly. And I'm still not convinced that this should be discussed in the mechanism spec, since it applies much more widely than just CRAM. 2222bis seems to me to be a better place to lay this out. That said, I have to rev the CRAM draft again for other (editorial) reasons, so if someone can come up with a diff to -01 I'll incorporate it. (Or is Kurt's paragraph above clear enough?) --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB52Loib038132 for ; Thu, 4 Dec 2003 18:21:50 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB52LoSW038131 for ietf-sasl-bks; Thu, 4 Dec 2003 18:21:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB52Lmib038123 for ; Thu, 4 Dec 2003 18:21:49 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from [192.168.1.102] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id hB52Lm40007250; Thu, 4 Dec 2003 19:21:49 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Thu, 04 Dec 2003 18:21:45 -0800 From: Lyndon Nerenberg To: "Kurt D. Zeilenga" , ietf-sasl@imc.org Subject: Re: PLAIN examples Message-ID: <2147483647.1070562105@[192.168.42.6]> In-Reply-To: <6.0.0.22.0.20031203153456.09152800@127.0.0.1> References: <6.0.0.22.0.20031203153456.09152800@127.0.0.1> X-Mailer: Mulberry/3.1.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on orthanc.ca Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > C: JaneJohnxipj3plmq I would change Jane and John to something not quite so similar, just to make the distinction more obvious. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4JDYib017771 for ; Thu, 4 Dec 2003 11:13:34 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB4JDYcc017770 for ietf-sasl-bks; Thu, 4 Dec 2003 11:13:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4JDWib017761 for ; Thu, 4 Dec 2003 11:13:32 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.9) with ESMTP id hB4JDY50001433 for ; Thu, 4 Dec 2003 19:13:34 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031204105707.03c7d860@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 04 Dec 2003 11:12:35 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: Proposed new slate of milestones for SASL WG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The chairs propose updating our slate of milestones to: Done Submit revised SASL (+ EXTERNAL) I-D Done Submit revised SASL ANONYMOUS I-D Done Submit revised SASL PLAIN I-D Done Submit revised SASL CRAM-MD5 I-D Done Submit revised SASL DIGEST-MD5 I-D Done Submit revised SASL GSSAPI I-D Jan 04 Submit SASL (+ EXTERNAL), SASLprep, ANONYMOUS, PLAIN to IESG for consideration as Proposed Standards Feb 04 Submit CRAM-MD5 to IESG for consideration as a Proposed Standard Mar 04 Submit DIGEST-MD5 to IESG for consideration as a Proposed Standard May 04 Submit GSSAPI to IESG for consideration as a Proposed Standard Jun 04 Provide implementation report plan (with milestones) Aug 04 Revise charter or conclude Note that the milestone dates are basically those suggested at IETF#58 but slipped a month or so. Note as well that this slate calls for all of the revised SASL specifications, including the rfc2222bis I-D, to be recycled at Proposed. This is mainly due to the introduction of SASLprep (which even the rfc2222bis I-D normatively references). If you have comments/concerns regarding this slate, please post them within the next week or so. The chairs plan on making a decision regarding what slate of milestones to progressed to our AD by 19th of this month. Kurt, SASL WG co-chair Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3Nbuib088745 for ; Wed, 3 Dec 2003 15:37:56 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3Nbu1k088744 for ietf-sasl-bks; Wed, 3 Dec 2003 15:37:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB3Nbsib088739 for ; Wed, 3 Dec 2003 15:37:55 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa14075; 3 Dec 2003 18:37 EST Date: Wed, 03 Dec 2003 18:37:13 -0500 From: Jeffrey Hutzelman To: Simon Josefsson , Sam Hartman cc: ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt Message-ID: <58040000.1070494633@minbar.fac.cs.cmu.edu> In-Reply-To: References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wednesday, December 03, 2003 19:56:03 +0100 Simon Josefsson wrote: > I don't see a conflict with this and the text I proposed, but I'm not > sure if you argue for or against the text. In fact, the problem of > forward compatible databases was the motivation for my text. The text > would help if SASLPrepX(SASLPrep(string)) != SASLPrepX(string) where > SASLPrepX is any future revision of SASLPrep. Yeah; that's supposed to be a guarantee. Part of this is spelled out in RFC2454, at the end of section 3 and in section 7.1: Authors of profiles of this document need to consider the effects of changing the mapping of any currently-assigned character when updating their profiles. Adding a new mapping for a currently- assigned character, or changing an existing mapping, could cause a variance between the behavior of systems that have been updated and systems that have not been updated. A subsequent version of a profile that references a newer version of a repertoire with new code points will inherently have some code points move from category U to either D, MN, or AO. For backwards compatibility, a subsequent version of a profile MUST NOT move code points from any other category. That is, current AO, MN, or D code points MUST NOT ever change to a different category. The rest comes from Unicode itself, which guarantees that normalizations for existing code points will not change. Sadly, it appears the UTC has been willing to violate that guarantee in some cases. > This is not the only interpretation. It is possible to consider the > SASL library to be performing a query against the HMAC-MD5 oracle to > decide whether a Unicode string the library received from the > application (possibly ultimately from a database), after the library > has prepared it with SASLPrep with AllowUnassigned set to true, is the > same secret used by the client. This critical issue is that for servers where a partial MD5 context is stored based on the shared secret, the secret MUST first be prepared according to SASLprep. In this case, the secret needs to be treated as a storage string -- there's no way to reverse the context establishment, so if the string was not normalized correctly to begin with, you can't go back and fix it when you upgrade. Thus, unassigned code points MUST NOT be permitted in such a case. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA > >>> If the answer is yes, I don't agree, because that would make CRAM-MD5 >>> reject passwords containing characters introduced by Unicode 4.0.0. >> >> As intended! Until stringprep is updated to detail how these >> newly assigned code points are to be handled, we need to exclude >> them from appearing in the "stored" password string. > > The behaviour of inputting Unicode 4.0.0 characters should still be > well defined. The current text say nothing about what the server > should do, so rejecting the input isn't the only alternative. > > Thanks, > Simon > > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3Na3ib088696 for ; Wed, 3 Dec 2003 15:36:03 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3Na3sT088695 for ietf-sasl-bks; Wed, 3 Dec 2003 15:36:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3Na0ib088689 for ; Wed, 3 Dec 2003 15:36:02 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hB3Na2lg035083 for ; Wed, 3 Dec 2003 23:36:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031203153456.09152800@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 03 Dec 2003 15:35:04 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: PLAIN 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: Here are the updated examples section: This section provides examples of PLAIN authentication exchanges. The examples are intended to help the readers understand the above text. The examples are not definitive. "C:" and "S:" indicate lines sent by the client and server respectively. "" represents a single NUL (U+0000) character. The Application Configuration Access Protocol ([ACAP]) is used in the examples. The first example shows how the PLAIN mechanism might be used for user authentication. S: * ACAP (SASL "CRAM-MD5") (STARTTLS) C: a001 STARTTLS S: a001 OK "Begin TLS negotiation now" S: * ACAP (SASL "CRAM-MD5" "PLAIN") C: a002 AUTHENTICATE "PLAIN" S: + "" C: {21} C: timtanstaaftanstaaf S: a002 OK "Authenticated" The second example shows how the PLAIN mechanism might be used to assuming the identity of another user. In this example, the server rejects the request. Also, this example makes use of the protocol optional initial response capability to eliminate a round-trip. S: * ACAP (SASL "CRAM-MD5") (STARTTLS) C: a001 STARTTLS S: a001 OK "Begin TLS negotiation now" S: * ACAP (SASL "CRAM-MD5" "PLAIN") C: a002 AUTHENTICATE "PLAIN" {19+} C: JaneJohnxipj3plmq S: a002 NO "Not authorized to assume asserted identity" Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3MSJib086040 for ; Wed, 3 Dec 2003 14:28:19 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3MSJka086039 for ietf-sasl-bks; Wed, 3 Dec 2003 14:28:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3MSIib086034 for ; Wed, 3 Dec 2003 14:28:18 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hB3MSKlg034367 for ; Wed, 3 Dec 2003 22:28:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031203141404.0913d728@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 03 Dec 2003 14:27:23 -0800 To: ietf-sasl@imc.org From: "Kurt D. Zeilenga" Subject: PLAIN and unassigned characters (Was: draft-ietf-sasl-crammd5-01.txt) In-Reply-To: <6.0.0.22.0.20031203123841.02784828@127.0.0.1> References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> <6.0.0.22.0.20031203123841.02784828@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: In consideration of the on-going CRAM-MD5 unassigned code point discussions, I reviewed draft-ietf-sasl-plain-xx.txt handling in this area and found that a few additional words would add clarity in this area. Hence, I'd like to make the following change: @@ -151,10 +151,12 @@ The presented authentication identity and password strings are not to be compared directly with stored strings. The server SHALL first prepare authentication identity and password strings using the [SASLPrep] profile of the [StringPrep] algorithm. +Per Section 7 of [StringPrep], unassigned code points may appear in +prepared presented (query) strings but are prohibited in stored strings. If preparation fails or results in an empty string, verification SHALL fail. If the server stores only the hash of expected string, the string MUST be prepared before generation of the hash. (+ indicates new text) Additionally (as previously discussed), I'll update the pseudo code such that SASLprep() takes a second argument as follows: +The second parameter of the SASLprep function, when true, indicates +that the input string is a "query" string [StringPrep] and, hence, +unassigned code points are allowed. When the SASLprep function is +called to prepared the password prior to computing the stored hash, +the second parameter would be false as unassigned code points are +not allowed in "stored strings" [StringPrep]. Kurt At 01:05 PM 12/3/2003, Kurt D. Zeilenga wrote: >At 10:56 AM 12/3/2003, Simon Josefsson wrote: >>"Kurt D. Zeilenga" writes: >> >>> In each of the password-based mechanisms (PLAIN, CRAM-MD5, >>> DIGEST-MD5, etc.), the user provided string is clear a "query" >>> string and the string which it is compared against (directly >>> or indirectly) is a "stored" string (regardless of whether >>> the server stores it locally or in some external systems). >> >>This is not the only interpretation. It is possible to consider the >>SASL library to be performing a query against the HMAC-MD5 oracle to >>decide whether a Unicode string the library received from the >>application (possibly ultimately from a database), after the library >>has prepared it with SASLPrep with AllowUnassigned set to true, is the >>same secret used by the client. > >Well, maybe the language I used was not clear enough. > >My point is that the mechanism specification must clearly >state which strings are query strings and which strings are >stored strings and ensure that two query strings prepared >by different implementations are not (directly or indirectly) >compared. > >The client copy of the user name and shared secret should >be defined as query strings and, hence, unassigned code points >are allowed to appear in the prepared output. The server >copy of the user name and shared secret should be viewed >as stored strings and, hence, unassigned code points are not >allowed to appear in the prepared output. > >The draft needs to be revised to make this clear. > >Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3LaYib082725 for ; Wed, 3 Dec 2003 13:36:34 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3LaY4I082724 for ietf-sasl-bks; Wed, 3 Dec 2003 13:36:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3LaWib082719 for ; Wed, 3 Dec 2003 13:36:32 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hB3LaX5G028697; Wed, 3 Dec 2003 16:36:33 -0500 Date: Wed, 3 Dec 2003 16:36:33 -0500 (EST) From: Rob Siemborski To: Sam Hartman cc: ietf-sasl@imc.org Subject: Re: Moving to rfc2222bis last call In-Reply-To: <20031201174409.A27F91515F2@konishi-polis.mit.edu> Message-ID: References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 1 Dec 2003, Sam Hartman wrote: > What are we still waiting on before the next last call of this > document? >From the minutes, we need to see an updated security considerations section (for the MITM attack), and we need examples for the initial client response and server last sends. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3L6oib081477 for ; Wed, 3 Dec 2003 13:06:50 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3L6oRM081476 for ietf-sasl-bks; Wed, 3 Dec 2003 13:06:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3L6nib081471 for ; Wed, 3 Dec 2003 13:06:49 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hB3L6glg033478; Wed, 3 Dec 2003 21:06:42 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031203123841.02784828@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 03 Dec 2003 13:05:45 -0800 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-sasl-crammd5-01.txt Cc: Sam Hartman , Jeffrey Hutzelman , ietf-sasl@imc.org In-Reply-To: References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:56 AM 12/3/2003, Simon Josefsson wrote: >"Kurt D. Zeilenga" writes: > >> In each of the password-based mechanisms (PLAIN, CRAM-MD5, >> DIGEST-MD5, etc.), the user provided string is clear a "query" >> string and the string which it is compared against (directly >> or indirectly) is a "stored" string (regardless of whether >> the server stores it locally or in some external systems). > >This is not the only interpretation. It is possible to consider the >SASL library to be performing a query against the HMAC-MD5 oracle to >decide whether a Unicode string the library received from the >application (possibly ultimately from a database), after the library >has prepared it with SASLPrep with AllowUnassigned set to true, is the >same secret used by the client. Well, maybe the language I used was not clear enough. My point is that the mechanism specification must clearly state which strings are query strings and which strings are stored strings and ensure that two query strings prepared by different implementations are not (directly or indirectly) compared. The client copy of the user name and shared secret should be defined as query strings and, hence, unassigned code points are allowed to appear in the prepared output. The server copy of the user name and shared secret should be viewed as stored strings and, hence, unassigned code points are not allowed to appear in the prepared output. The draft needs to be revised to make this clear. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3Kagib080248 for ; Wed, 3 Dec 2003 12:36:42 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3Kagbh080247 for ietf-sasl-bks; Wed, 3 Dec 2003 12:36:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-NINETEEN.MIT.EDU [18.187.5.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3Kafib080242 for ; Wed, 3 Dec 2003 12:36:41 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 92F411515F2; Wed, 3 Dec 2003 15:36:37 -0500 (EST) To: Simon Josefsson Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Wed, 03 Dec 2003 15:36:37 -0500 In-Reply-To: (Simon Josefsson's message of "Wed, 03 Dec 2003 21:34:08 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Simon" == Simon Josefsson writes: Simon> Sam Hartman writes: >>>>>>> "Simon" == Simon Josefsson writes: >> Simon> I'm sorry to be dense, but can you be more specific? I Simon> thought future stringprep profiles were allowed to use Simon> Unicode 4.0.0, including the correct normalization tables, Simon> but if SASLPrep2 would do so, the above guarantee doesn't Simon> hold. >> The problem here being that normalization changed between 3.2 >> and 4.0 in incompatible ways? Simon> That's one example of the problem, yes. In general, I Simon> didn't find any guarantee that a future version of a Simon> stringprep profile must be backwards compatible to the Simon> previous version. For SASLPrep, that could be useful, but Simon> I haven't found any place that say it must be so. If there Simon> isn't, storing the unprepared string in databases appear to Simon> be the safe recommendation. (It might be anyway, if the Simon> database is shared with other password infrastructures that Simon> doesn't use SASLPrep, but that's besides the point.) It's my understanding that the entire IETF internationalization architecture as it depends on stringprep depends on this guarantee. Sort of unfortunate that it is not stated. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3KYOib080168 for ; Wed, 3 Dec 2003 12:34:24 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3KYONp080167 for ietf-sasl-bks; Wed, 3 Dec 2003 12:34:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3KYMib080162 for ; Wed, 3 Dec 2003 12:34:22 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.10/8.12.10) with ESMTP id hB3KYKrh006966 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 3 Dec 2003 21:34:21 +0100 To: Sam Hartman Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Simon Josefsson X-Payment: hashcash 1.2 0:031203:hartmans@mit.edu:f03ce38d97c49e19 X-Hashcash: 0:031203:hartmans@mit.edu:f03ce38d97c49e19 X-Payment: hashcash 1.2 0:031203:jhutz@cmu.edu:80f7ade3ca434606 X-Hashcash: 0:031203:jhutz@cmu.edu:80f7ade3ca434606 X-Payment: hashcash 1.2 0:031203:ietf-sasl@imc.org:e81851d0b8e5db8d X-Hashcash: 0:031203:ietf-sasl@imc.org:e81851d0b8e5db8d Date: Wed, 03 Dec 2003 21:34:08 +0100 In-Reply-To: (Sam Hartman's message of "Wed, 03 Dec 2003 14:43:29 -0500") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: >>>>>> "Simon" == Simon Josefsson writes: > > > Simon> I'm sorry to be dense, but can you be more specific? I > Simon> thought future stringprep profiles were allowed to use > Simon> Unicode 4.0.0, including the correct normalization tables, > Simon> but if SASLPrep2 would do so, the above guarantee doesn't > Simon> hold. > > The problem here being that normalization changed between 3.2 and 4.0 > in incompatible ways? That's one example of the problem, yes. In general, I didn't find any guarantee that a future version of a stringprep profile must be backwards compatible to the previous version. For SASLPrep, that could be useful, but I haven't found any place that say it must be so. If there isn't, storing the unprepared string in databases appear to be the safe recommendation. (It might be anyway, if the database is shared with other password infrastructures that doesn't use SASLPrep, but that's besides the point.) Thanks, Simon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3JhVib077914 for ; Wed, 3 Dec 2003 11:43:31 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3JhVRc077913 for ietf-sasl-bks; Wed, 3 Dec 2003 11:43:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-NINETEEN.MIT.EDU [18.187.5.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3JhUib077907 for ; Wed, 3 Dec 2003 11:43:30 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id A35FB1515F2; Wed, 3 Dec 2003 14:43:29 -0500 (EST) To: Simon Josefsson Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Wed, 03 Dec 2003 14:43:29 -0500 In-Reply-To: (Simon Josefsson's message of "Wed, 03 Dec 2003 20:35:33 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Simon" == Simon Josefsson writes: Simon> I'm sorry to be dense, but can you be more specific? I Simon> thought future stringprep profiles were allowed to use Simon> Unicode 4.0.0, including the correct normalization tables, Simon> but if SASLPrep2 would do so, the above guarantee doesn't Simon> hold. The problem here being that normalization changed between 3.2 and 4.0 in incompatible ways? Well, that's sort of an open issue within the IETF because that wasn't supposed to happen. Stringprep assumes normalization never changes; we assume that future versions of stringprep onlly change in handling of unassigned codepoints. Unicode has created a mess for us and we have not decided how to deal. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3JZrib077631 for ; Wed, 3 Dec 2003 11:35:53 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3JZruM077630 for ietf-sasl-bks; Wed, 3 Dec 2003 11:35:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3JZpib077624 for ; Wed, 3 Dec 2003 11:35:52 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.10/8.12.10) with ESMTP id hB3JZkrh005664 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 3 Dec 2003 20:35:46 +0100 To: Sam Hartman Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Simon Josefsson X-Payment: hashcash 1.2 0:031203:hartmans@mit.edu:4929e304894508c6 X-Hashcash: 0:031203:hartmans@mit.edu:4929e304894508c6 X-Payment: hashcash 1.2 0:031203:jhutz@cmu.edu:a6a81735d4c0c035 X-Hashcash: 0:031203:jhutz@cmu.edu:a6a81735d4c0c035 X-Payment: hashcash 1.2 0:031203:ietf-sasl@imc.org:90616f6c18f9afc5 X-Hashcash: 0:031203:ietf-sasl@imc.org:90616f6c18f9afc5 Date: Wed, 03 Dec 2003 20:35:33 +0100 In-Reply-To: (Sam Hartman's message of "Wed, 03 Dec 2003 14:17:39 -0500") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: >>>>>> "Simon" == Simon Josefsson writes: > > Simon> If SASLPrepX is guaranteed to behave the same as SASLPrep > Simon> for currently assigned characters, there is no problem in > Simon> storing SASLPrep prepared strings in the database, and my > Simon> text is incorrect. However, in that case, I believe the > Simon> guarantee that SASLPrepX(SASLPrep(string)) = > Simon> SASLPrepX(string) should be stated in the SASLPrep > Simon> document. > > I believe this guarantee is stated in stringprep. I'm sorry to be dense, but can you be more specific? I thought future stringprep profiles were allowed to use Unicode 4.0.0, including the correct normalization tables, but if SASLPrep2 would do so, the above guarantee doesn't hold. Thanks, Simon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3JHfib076872 for ; Wed, 3 Dec 2003 11:17:41 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3JHf06076871 for ietf-sasl-bks; Wed, 3 Dec 2003 11:17:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-NINETEEN.MIT.EDU [18.187.5.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3JHeib076864 for ; Wed, 3 Dec 2003 11:17:40 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id B1E9D1515F2; Wed, 3 Dec 2003 14:17:39 -0500 (EST) To: Simon Josefsson Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Wed, 03 Dec 2003 14:17:39 -0500 In-Reply-To: (Simon Josefsson's message of "Wed, 03 Dec 2003 19:56:03 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Simon" == Simon Josefsson writes: Simon> If SASLPrepX is guaranteed to behave the same as SASLPrep Simon> for currently assigned characters, there is no problem in Simon> storing SASLPrep prepared strings in the database, and my Simon> text is incorrect. However, in that case, I believe the Simon> guarantee that SASLPrepX(SASLPrep(string)) = Simon> SASLPrepX(string) should be stated in the SASLPrep Simon> document. I believe this guarantee is stated in stringprep. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3J8sib076615 for ; Wed, 3 Dec 2003 11:08:54 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3J8sQ7076614 for ietf-sasl-bks; Wed, 3 Dec 2003 11:08:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-NINETEEN.MIT.EDU [18.187.5.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3J8rib076608 for ; Wed, 3 Dec 2003 11:08:53 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 8ABAC1515F2; Wed, 3 Dec 2003 14:08:52 -0500 (EST) To: ietf-sasl@imc.org Subject: Draft Minutes for SASL working group meeting From: Sam Hartman Date: Wed, 03 Dec 2003 14:08:52 -0500 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please comment; I'll submit at the end of the week or the proceedings deadline, whichever is sooner. From: Philip Guenther Minutes for IETF 58 SASL Working Group scribe: Philip Guenther guenther@sendmail.com chairs: Sam Hartman , Kurt Zeilenga agenda change: - add short discussion of private-use characters in saslprep status of drafts: - base-spec last call was not discussed in previous meeting, but it has been last called since then - saslprep has been last called, but generated no comments at that time. fullstop issue arose after that - Alexey taking on editorship of gssapi mech draft - digests and cram-md5 updated to support stringprep - plain mech to be clarified. When applying saslprep, is a query string or a stored string, as that affects unassigned characters - example to be added showing no initial first reply - example to be added showing non-empty authorization ID - example to be added showing failure vs success - *not* to clarify SMTP usage or use SMTP instead of ACAP Rob Siemborski (speaking for Alexey): - 2222bis: - discussion of attack if the security layer is *not* dropped on reauthentication: - attack: - client authenticates to realm A (monitored by B) - reauthenticates to realm B w/o dropping the layer - realm B server now has an oracle on the confidentiality layer - the chairs noted that the risk of attack is related to the trust relationships in the server setup - poll of room re: how to handle - 15 to zero in favor of documenting in the security considerations and not altering the SASL requirement - the option of leaving it up to the protocol profile was considered by some to be an even worse choice due to the extra complexity it introduces. - will be taken to list for confirmation of consensus - consider adding text: client should check to verify that a MITM attack didn't remove mechanisms from the list by checking after - believed to be resolved with careful wording Kurt: - last call on saslprep draft - fullstop issue - some discussion on list - Ienup Sung presents: why fullstop != . - defs from unicode: - U+002E defined not just as period but also for decimals - U+3002 has U+002E as reference, not equivalence - U+FF0E (fullwidth period) *is* equivalent to U+002E - NFKC reflects this - ideographics stops are *only* used in text, not as decimal point (this is stricter in Japan and China than in Korea) - ergo: they should only be in the same equivalence class for internet style domain names (IDNA) and *not* in saslprep - - comments [confusing to follow] - Jeff Altman: - wording by Ienup seems to be that decimal *can* be used in text - therefore, *should* do mapping because users might not be able to control it - Marc Crispin:Please provide an example of a real world situation where this is a problem. - Paul Hoffman: - if you believe that normal names that will be used in sasl will include periods that will be used in context-sensitive ways, then do not to the mapping - Ienup: - feels that parens vs bracket in english is an analogous situations - Jeff Altman: - no, saslprep shouldn't always do the mapping; but that mechs should overide that for saslprep usages that specify things like domain-name-like items - Marc Crispin: - does not seem credibile that the mapping is necessary - wants credible example - Nico Williams: - felt that credible example was given, thinks that it may be a UI issue - private-use characters - suggestion by Jeff Altman that private-use char restriction should be removed and replaced with discussion of usages and lack of interoperability - characters not yet in unicode from previous charsets including experimental and those in internal use in corps - ?would require normalization of private-use characters? - Ienup: - saslprep prohibits them - some text cannot be entered without these - there is some need, understand problems and issues need to make clear that this is limited use - Kurt: - cannot just drop prohibition because too much is defined privately - chair: show of hands to go forward with even considering - 4 hands for - 5 hands against - Michel: - extremely bad idea - no semantic defined - not stable - even inside same organization, different usages may exist - no temporal stability - Paul Hoffman: - all that, plus, this is for identifiers and password only - name that requires private use character is unlikely - will be taken back to the list - Rob: SMTP AUTH - proposal to add initial response to IMAP - issue is in the rfcs, it's just not clear - new pop3 and smtp profile drafts - cleanup, add examples, fill in gaps - especially cases showing failing to send initial response - consensus on list was to *not* change examples in sasl plain from ACAP to SMTP - examples of initial client response and server last challenge *will* be added to rfc2222bis - WG wrap up - milestones - GSSAPI I-D is still missing, Alexey says new version should be out by end of November - implementation report to be pushed out because recycling at proposed - (or maybe not? chairs to discuss); base may not need recycling - base is ready for last call - plain has minor tweaks, needs last call - anonymous is ready - saslprep has minor issues - cram-md5 and digest-md5 need a little more work before last call Alexey has dealt with CBC issues but missed cut-off before meeting - base, plain, anonymous, and saslprep before end of year - digest + cram shortly thereafter - gssapi by, say, May? - Bob Morgan - FYI: OASIS has interest in defining a SASL mech doing single-sign-on expect note to mailing list Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3IuMib076217 for ; Wed, 3 Dec 2003 10:56:22 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3IuMVN076216 for ietf-sasl-bks; Wed, 3 Dec 2003 10:56:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3IuKib076197 for ; Wed, 3 Dec 2003 10:56:20 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.10/8.12.10) with ESMTP id hB3IuGrh004892 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 3 Dec 2003 19:56:16 +0100 To: Sam Hartman Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Simon Josefsson X-Payment: hashcash 1.2 0:031203:hartmans@mit.edu:0dcae58eca711d66 X-Hashcash: 0:031203:hartmans@mit.edu:0dcae58eca711d66 X-Payment: hashcash 1.2 0:031203:jhutz@cmu.edu:ab1890be4cc6d30a X-Hashcash: 0:031203:jhutz@cmu.edu:ab1890be4cc6d30a X-Payment: hashcash 1.2 0:031203:ietf-sasl@imc.org:82b60170ff38f502 X-Hashcash: 0:031203:ietf-sasl@imc.org:82b60170ff38f502 Date: Wed, 03 Dec 2003 19:56:03 +0100 In-Reply-To: (Sam Hartman's message of "Wed, 03 Dec 2003 12:21:28 -0500") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: > I mean that this should be a requirement for interoperability in the > long term. If you don't have this requirement, then you may run into > cases where saslprep eventually maps out those characters in the > future. > > Basically, if we require allowunassigned to be false, we guarantee > future interoperability at the cost of refusing to allow people to use > unassigned characters until saslprep is updated. I don't see a conflict with this and the text I proposed, but I'm not sure if you argue for or against the text. In fact, the problem of forward compatible databases was the motivation for my text. The text would help if SASLPrepX(SASLPrep(string)) != SASLPrepX(string) where SASLPrepX is any future revision of SASLPrep. If SASLPrepX is guaranteed to behave the same as SASLPrep for currently assigned characters, there is no problem in storing SASLPrep prepared strings in the database, and my text is incorrect. However, in that case, I believe the guarantee that SASLPrepX(SASLPrep(string)) = SASLPrepX(string) should be stated in the SASLPrep document. "Kurt D. Zeilenga" writes: > In each of the password-based mechanisms (PLAIN, CRAM-MD5, > DIGEST-MD5, etc.), the user provided string is clear a "query" > string and the string which it is compared against (directly > or indirectly) is a "stored" string (regardless of whether > the server stores it locally or in some external systems). This is not the only interpretation. It is possible to consider the SASL library to be performing a query against the HMAC-MD5 oracle to decide whether a Unicode string the library received from the application (possibly ultimately from a database), after the library has prepared it with SASLPrep with AllowUnassigned set to true, is the same secret used by the client. >>If the answer is yes, I don't agree, because that would make CRAM-MD5 >>reject passwords containing characters introduced by Unicode 4.0.0. > > As intended! Until stringprep is updated to detail how these > newly assigned code points are to be handled, we need to exclude > them from appearing in the "stored" password string. The behaviour of inputting Unicode 4.0.0 characters should still be well defined. The current text say nothing about what the server should do, so rejecting the input isn't the only alternative. Thanks, Simon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3HLUib070096 for ; Wed, 3 Dec 2003 09:21:30 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3HLUGW070095 for ietf-sasl-bks; Wed, 3 Dec 2003 09:21:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-NINETEEN.MIT.EDU [18.187.5.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3HLSib070090 for ; Wed, 3 Dec 2003 09:21:28 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id AF9971515F2; Wed, 3 Dec 2003 12:21:28 -0500 (EST) To: Simon Josefsson Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Wed, 03 Dec 2003 12:21:28 -0500 In-Reply-To: (Simon Josefsson's message of "Wed, 03 Dec 2003 01:21:04 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Simon" == Simon Josefsson writes: Simon> I'm having trouble understanding what these statements Simon> imply for the protocol. Perhaps my trouble is because the Simon> discussion is now focused on the database, and not on the Simon> protocol. Simon> Do you mean that servers will be _required_ to use Simon> passwords prepared with AllowUnassigned false in the Simon> HMAC-MD5 computation? I mean that this should be a requirement for interoperability in the long term. If you don't have this requirement, then you may run into cases where saslprep eventually maps out those characters in the future. Basically, if we require allowunassigned to be false, we guarantee future interoperability at the cost of refusing to allow people to use unassigned characters until saslprep is updated. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB34Amib068338 for ; Tue, 2 Dec 2003 20:10:48 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB34AmZP068337 for ietf-sasl-bks; Tue, 2 Dec 2003 20:10:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB34Akib068332 for ; Tue, 2 Dec 2003 20:10:46 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hB34Aelg023477; Wed, 3 Dec 2003 04:10:41 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031202193544.02757990@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 02 Dec 2003 20:09:44 -0800 To: Simon Josefsson From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-sasl-crammd5-01.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 04:21 PM 12/2/2003, Simon Josefsson wrote: > Regardless of whether the prepared string is ever stored in a > database? First, I think "in a database" is a unnecessary qualification. All that matters is that it is a "stored" string per stringprep. In each of the password-based mechanisms (PLAIN, CRAM-MD5, DIGEST-MD5, etc.), the user provided string is clear a "query" string and the string which it is compared against (directly or indirectly) is a "stored" string (regardless of whether the server stores it locally or in some external systems). > Perhaps my trouble is because the discussion is now focused > on the database, and not on the protocol. I do think that it should be considered an implementation detail whether the server applies SASLprep with unassigned disallowed before or after use storage. What matters to the protocol/algorithm is the server apply the SASLprep with disallowed before comparison to the "stored" string. Generally, doing it before storage is more appropriate. However, there is no harm (and there may be advantage in some instances (e.g., external password stores)) of doing it after fetching it from storage (BUT before comparison). So, maybe we're agreeing... >If the answer is yes, I don't agree, because that would make CRAM-MD5 >reject passwords containing characters introduced by Unicode 4.0.0. As intended! Until stringprep is updated to detail how these newly assigned code points are to be handled, we need to exclude them from appearing in the "stored" password string. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB30LKib061041 for ; Tue, 2 Dec 2003 16:21:20 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB30LKv8061040 for ietf-sasl-bks; Tue, 2 Dec 2003 16:21:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB30LIib061034 for ; Tue, 2 Dec 2003 16:21:19 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.10/8.12.10) with ESMTP id hB30LGrh016695 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 3 Dec 2003 01:21:16 +0100 To: Sam Hartman Cc: Jeffrey Hutzelman , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Simon Josefsson X-Payment: hashcash 1.2 0:031203:hartmans@mit.edu:c80f5a86ea7835da X-Hashcash: 0:031203:hartmans@mit.edu:c80f5a86ea7835da X-Payment: hashcash 1.2 0:031203:jhutz@cmu.edu:16e069d1593831ca X-Hashcash: 0:031203:jhutz@cmu.edu:16e069d1593831ca X-Payment: hashcash 1.2 0:031203:ietf-sasl@imc.org:eb01571a02ef3851 X-Hashcash: 0:031203:ietf-sasl@imc.org:eb01571a02ef3851 Date: Wed, 03 Dec 2003 01:21:04 +0100 In-Reply-To: (Sam Hartman's message of "Tue, 02 Dec 2003 14:31:20 -0500") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: >>>>>> "Jeffrey" == Jeffrey Hutzelman writes: > > Jeffrey> The correct way to handle this situation is to require > Jeffrey> that if the server stores the prepared string (or maybe, > Jeffrey> even if not), the server prepare the string with > Jeffrey> AllowUnassigned set to FALSE, thereby prohibiting > Jeffrey> unassigned code points. If the server stores the > Jeffrey> prepared string, then it is properly a "storage string" > Jeffrey> and should not be permitted to contain unassigned code > Jeffrey> points. > > > I agree. I believe cram-md5 should always treat the secret as a > storage string when it is updating its database. I'm having trouble understanding what these statements imply for the protocol. Perhaps my trouble is because the discussion is now focused on the database, and not on the protocol. Do you mean that servers will be _required_ to use passwords prepared with AllowUnassigned false in the HMAC-MD5 computation? Regardless of whether the prepared string is ever stored in a database? If the answer is yes, I don't agree, because that would make CRAM-MD5 reject passwords containing characters introduced by Unicode 4.0.0. Regards, Simon PS. Forward compatibility issues with StringPrep profiles are discussed in the recent draft-faltstrom-unicode-synchronisation-00. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2JVMib036415 for ; Tue, 2 Dec 2003 11:31:23 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB2JVMRH036414 for ietf-sasl-bks; Tue, 2 Dec 2003 11:31:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2JVJib036406 for ; Tue, 2 Dec 2003 11:31:19 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 86F161515F2; Tue, 2 Dec 2003 14:31:20 -0500 (EST) To: Jeffrey Hutzelman Cc: Simon Josefsson , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt References: <1753870000.1070319902@minbar.fac.cs.cmu.edu> From: Sam Hartman Date: Tue, 02 Dec 2003 14:31:20 -0500 In-Reply-To: <1753870000.1070319902@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Mon, 01 Dec 2003 18:05:02 -0500") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> The correct way to handle this situation is to require Jeffrey> that if the server stores the prepared string (or maybe, Jeffrey> even if not), the server prepare the string with Jeffrey> AllowUnassigned set to FALSE, thereby prohibiting Jeffrey> unassigned code points. If the server stores the Jeffrey> prepared string, then it is properly a "storage string" Jeffrey> and should not be permitted to contain unassigned code Jeffrey> points. I agree. I believe cram-md5 should always treat the secret as a storage string when it is updating its database. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB29L4ib097014 for ; Tue, 2 Dec 2003 01:21:04 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB29L4uT097013 for ietf-sasl-bks; Tue, 2 Dec 2003 01:21:04 -0800 (PST) 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.10/8.12.8) with ESMTP id hB29L2ib096982 for ; Tue, 2 Dec 2003 01:21:03 -0800 (PST) (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 1AR6iJ-00047Q-QW; Tue, 02 Dec 2003 10:20:59 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.14) id 1AR6iF-0003uh-T0; Tue, 02 Dec 2003 10:20:55 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AR6iF-0007Sa-00; Tue, 2 Dec 2003 10:20:55 +0100 From: Hallvard B Furuseth Message-Id: To: hartmans@mit.edu (Sam Hartman) Cc: ietf-sasl@imc.org Subject: Re: Moving to rfc2222bis last call In-Reply-To: <20031201174409.A27F91515F2@konishi-polis.mit.edu> References: <20031201174409.A27F91515F2@konishi-polis.mit.edu> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 2 Dec 2003 10:20:55 +0100 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=-4.9, required 12, BAYES_00 -4.90) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman writes: > What are we still waiting on before the next last call of this > document? I think this document needs another version before it is ready for last call. Here is the unfinished business I'm aware of: ------------------------------------------------------------------------ The 'suggested text about multiple SASL mechanisms' thread. ------------------------------------------------------------------------ Subject: [Fwd: Keeping/dropping existing SASL security layer] From: Alexey Melnikov Date: Tue, 11 Nov 2003 20:35:01 +0000 Message-ID: <3FB147F5.3070902@isode.com> URL: http://www.imc.org/ietf-sasl/mail-archive/msg01312.html Alexey's attack when keeping an old security layer. He sent it to Rob and me before the list, and I replied that I still did not understand, with a list of where I got lost. ------------------------------------------------------------------------ Subject: Re: rfc2222bis: re-negotiating SASL security layer From: Hallvard B Furuseth Date: Tue, 11 Nov 2003 22:24:45 +0100 Message-Id: URL: http://www.imc.org/ietf-sasl/mail-archive/msg01313.html When can a security layer be removed? What I said in this message seems to reflect what Alexey said last, but I don't quite think that's what he meant... ------------------------------------------------------------------------ Subject: Re: rfc2222bis: protocol profile? From: Hallvard B Furuseth Date: Mon, 10 Nov 2003 08:10:22 +0100 Message-Id: URL: http://www.imc.org/ietf-sasl/mail-archive/msg01304.html What belongs in the protocol profile? ------------------------------------------------------------------------ Subject: draft-ietf-sasl-rfc2222bis-02.txt section 4.2 From: Tony Hansen Date: Thu, 06 Nov 2003 12:02:22 -0500 Message-ID: <3FAA7E9E.3080704@att.com> URL: http://www.imc.org/ietf-sasl/mail-archive/msg01278.html Split section 4.2 (Authorization identities and proxy authentication). It appears to be mixing two totally different discussions together in a slightly confusing mess. ------------------------------------------------------------------------ The 'selects no security layer' thread. I've lost track of this one and will have to reread it. But originally all I wanted was to clarify that specific phrase: either to 'does not select a security layer' or 'selects that there shall be no security layer', or whatever else is meant. That has not been done yet. ------------------------------------------------------------------------ -- Hallvard Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1N5Vib011780 for ; Mon, 1 Dec 2003 15:05:31 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB1N5ViH011779 for ietf-sasl-bks; Mon, 1 Dec 2003 15:05:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB1N5Uib011773 for ; Mon, 1 Dec 2003 15:05:30 -0800 (PST) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa09435; 1 Dec 2003 18:05 EST Date: Mon, 01 Dec 2003 18:05:02 -0500 From: Jeffrey Hutzelman To: Simon Josefsson , ietf-sasl@imc.org Subject: Re: draft-ietf-sasl-crammd5-01.txt Message-ID: <1753870000.1070319902@minbar.fac.cs.cmu.edu> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Monday, December 01, 2003 23:39:51 +0100 Simon Josefsson wrote: > I suggest adding: > > The server MUST prepare the shared secret string using the > [SASLPrep] profile of the [StringPrep] algorithm. The resulting > value MUST be encoded as UTF-8 [UTF8]. The server may store the > prepared string instead of, or as well as, the unprepared > string, so that it does not have to prepare it every time it is > needed for computation. However, if the original, unprepared > string, is not stored, it may render the computed secret to be > incompatible with a future revisions of SASLPrep that support > currently unassigned code points (compare section 7 of > [StringPrep]). It is therefor recommended to store the > unprepared string in the database. The correct way to handle this situation is to require that if the server stores the prepared string (or maybe, even if not), the server prepare the string with AllowUnassigned set to FALSE, thereby prohibiting unassigned code points. If the server stores the prepared string, then it is properly a "storage string" and should not be permitted to contain unassigned code points. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1Me4ib011085 for ; Mon, 1 Dec 2003 14:40:04 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB1Me4gL011084 for ietf-sasl-bks; Mon, 1 Dec 2003 14:40:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1Me0ib011076 for ; Mon, 1 Dec 2003 14:40:03 -0800 (PST) (envelope-from jas@extundo.com) Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.10/8.12.10) with ESMTP id hB1Me0rh017766 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 1 Dec 2003 23:40:01 +0100 To: ietf-sasl@imc.org Subject: draft-ietf-sasl-crammd5-01.txt From: Simon Josefsson X-Payment: hashcash 1.2 0:031201:ietf-sasl@imc.org:0b9356fad30d5eac X-Hashcash: 0:031201:ietf-sasl@imc.org:0b9356fad30d5eac Date: Mon, 01 Dec 2003 23:39:51 +0100 Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, I have read the document. Some comments: ,---- | The client MUST prepare the user name and shared secret strings | using the [SASLPrep] profile of the [StringPrep] algorithm. The | resulting values MUST be encoded as UTF-8 [UTF8]. `---- I suggest adding: The server MUST prepare the shared secret string using the [SASLPrep] profile of the [StringPrep] algorithm. The resulting value MUST be encoded as UTF-8 [UTF8]. The server may store the prepared string instead of, or as well as, the unprepared string, so that it does not have to prepare it every time it is needed for computation. However, if the original, unprepared string, is not stored, it may render the computed secret to be incompatible with a future revisions of SASLPrep that support currently unassigned code points (compare section 7 of [StringPrep]). It is therefor recommended to store the unprepared string in the database. Also, the example section is incorrect. Suggested new version: S: * OK [CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED AUTH=CRAM-MD5] C: A0001 AUTHENTICATE CRAM-MD5 S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UuZXhhbXBsZS5uZXQ+ C: am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3 S: A0001 OK CRAM-MD5 authentication successful In this example, the shared secret is the string tanstaaftanstaaf Hence, the Keyed MD5 digest is produced by calculating MD5((tanstaaftanstaaf XOR opad), MD5((tanstaaftanstaaf XOR ipad), <1896.697170952@postoffice.example.net>)) where ipad and opad are as defined in [KEYED-MD5] and the string shown in the challenge is the base64 encoding of <1896.697170952@postoffice.example.net>. The shared secret is null-padded to a length of 64 bytes. If the shared secret is longer than 64 bytes, the MD5 digest of the shared secret is used as a 16 byte input to the keyed MD5 calculation. This produces a digest value (in hexadecimal) of 3dbc88f0624776a737b39093f6eb6427 The user name is then prepended to it, forming joe 3dbc88f0624776a737b39093f6eb6427 Which is then base64 encoded to meet the requirements of the IMAP4 AUTHENTICATE command (or the similar POP3 AUTH command), yielding am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3 Perhaps it would be useful to add an example for non-ASCII strings too, using or similar to indicate non-ASCII characters. Thanks, Simon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1M6iib009754 for ; Mon, 1 Dec 2003 14:06:44 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB1M6i7b009753 for ietf-sasl-bks; Mon, 1 Dec 2003 14:06:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1M6hib009747 for ; Mon, 1 Dec 2003 14:06:43 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 1CDE71515F2; Mon, 1 Dec 2003 17:06:44 -0500 (EST) To: "Kurt D. Zeilenga" Cc: Rob Siemborski , Hallvard B Furuseth , ietf-sasl@imc.org Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms References: <6.0.0.22.0.20031201131838.0426ae78@127.0.0.1> From: Sam Hartman Date: Mon, 01 Dec 2003 17:06:44 -0500 In-Reply-To: <6.0.0.22.0.20031201131838.0426ae78@127.0.0.1> (Kurt D. Zeilenga's message of "Mon, 01 Dec 2003 13:47:40 -0800") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Kurt" == Kurt D Zeilenga writes: Kurt> At 07:16 PM 11/14/2003, Sam Hartman wrote: >> One thing we need to keep in mind is that over time, we get a >> better idea of what best practices for using SASL are. Kurt> My operational experiences with LDAP show that making Kurt> available a list of mechanisms post authentication isn't the Kurt> "best" practice for preventing MITM downgrade attacks. Kurt> I think the "best" practice is for the client and server to Kurt> have policy which states what the levels of service are or Kurt> are not acceptable (and when). A simple mechanism can just Kurt> dictate minimum levels and refuse when not met. A more Kurt> complex mechanism could have two levels, minimum and Kurt> recommend, where less than recommended but higher than Kurt> minimum required user authorization. We all agree this is sufficient. However I believe that IETF experience with other security protocols strongly favors having a way to detect downgrades when possible. The problem is that in practice, people tend to establish fairly loose policies on their clients, so in situations where it is possible to detect the downgrade it is a good idea to do so. I agree there is not significant experience with this in the SASL community, but I believe there is sufficient experience in the SASL community to say that client policies do tend to be fairly lax and experience in the rest of the IETF to say that downgrade detection is desirable. I believe that is sufficient to provide advice for new protocols. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1Lmbib008660 for ; Mon, 1 Dec 2003 13:48:37 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB1LmbYS008659 for ietf-sasl-bks; Mon, 1 Dec 2003 13:48:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1LmZib008654 for ; Mon, 1 Dec 2003 13:48:35 -0800 (PST) (envelope-from Kurt@OpenLDAP.org) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hB1LmZlg001254; Mon, 1 Dec 2003 21:48:35 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031201131838.0426ae78@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 01 Dec 2003 13:47:40 -0800 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms Cc: Rob Siemborski , Hallvard B Furuseth , ietf-sasl@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 07:16 PM 11/14/2003, Sam Hartman wrote: >One thing we need to keep in mind is that over time, we get a better >idea of what best practices for using SASL are. My operational experiences with LDAP show that making available a list of mechanisms post authentication isn't the "best" practice for preventing MITM downgrade attacks. I think the "best" practice is for the client and server to have policy which states what the levels of service are or are not acceptable (and when). A simple mechanism can just dictate minimum levels and refuse when not met. A more complex mechanism could have two levels, minimum and recommend, where less than recommended but higher than minimum required user authorization. I think the list mechanism approach in LDAP is a bit problematic. First, SASL (or other) security layers may not have been established making the information subject to MITM attack. Second, LDAP allows the list of mechanisms to change based upon current availability (to this client). It is possible that a stronger mechanism is, for legitimate reasons, no longer available. It is not possible for the client to deduce why a change in the listing was made. A more workable approach would be to recommend the server provide a list of mechanisms which WERE available to the client when it authenticated to the server. Lastly, the list doesn't prevent any similar MITM attacks (for example, downgrading of the cipher suites used by a listed mechanism). I also note that I have yet to find a client which actually uses the list of available mechanisms to detect MITM attacks. Clients which do attempt to detect such attacks tend to use a policy based mechanism. In short, I don't think we have enough good operational experience to add these imperatives to the technical specification. Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1KUxib006007 for ; Mon, 1 Dec 2003 12:30:59 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB1KUxD8006006 for ietf-sasl-bks; Mon, 1 Dec 2003 12:30:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1KUwib005999 for ; Mon, 1 Dec 2003 12:30:58 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27449; Mon, 1 Dec 2003 15:30:46 -0500 (EST) Message-Id: <200312012030.PAA27449@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-crammd5-01.txt Date: Mon, 01 Dec 2003 15:30:46 -0500 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The CRAM-MD5 SASL Mechanism Author(s) : L. Nerenberg Filename : draft-ietf-sasl-crammd5-01.txt Pages : 7 Date : 2003-12-1 This document defines a simple challenge-response authentication mechanism, using a keyed-hash digest, for use with the Simple Authentication and Security Layer (SASL) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-crammd5-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-crammd5-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-1152419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-crammd5-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-crammd5-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-1152419.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1HiDib098345 for ; Mon, 1 Dec 2003 09:44:13 -0800 (PST) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB1HiD2H098344 for ietf-sasl-bks; Mon, 1 Dec 2003 09:44:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-ONE-O-NINE.MIT.EDU [18.187.5.109]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1HiAib098336 for ; Mon, 1 Dec 2003 09:44:12 -0800 (PST) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id A27F91515F2; Mon, 1 Dec 2003 12:44:09 -0500 (EST) To: ietf-sasl@imc.org Subject: Moving to rfc2222bis last call Message-Id: <20031201174409.A27F91515F2@konishi-polis.mit.edu> Date: Mon, 1 Dec 2003 12:44:09 -0500 (EST) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: What are we still waiting on before the next last call of this document?