From owner-ietf-sasl Tue Jul 1 04:23:53 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61BNrFK046736 for ; Tue, 1 Jul 2003 04:23:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61BNrNH046735 for ietf-sasl-bks; Tue, 1 Jul 2003 04:23:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61BNqFK046730 for ; Tue, 1 Jul 2003 04:23:53 -0700 (PDT) (envelope-from nsyracus@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 HAA07340; Tue, 1 Jul 2003 07:23:50 -0400 (EDT) Message-Id: <200307011123.HAA07340@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-rfc2831bis-02.txt Date: Tue, 01 Jul 2003 07:23:50 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Using Digest Authentication as a SASL Mechanism Author(s) : P. Leach, C. Newman, A. Melnikov Filename : draft-ietf-sasl-rfc2831bis-02.txt Pages : 39 Date : 2003-6-30 This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2831bis-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2831bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-30151553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2831bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-30151553.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Tue Jul 1 04:22:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61BMYFK046652 for ; Tue, 1 Jul 2003 04:22:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61BMY7W046651 for ietf-sasl-bks; Tue, 1 Jul 2003 04:22:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61BMWFK046646 for ; Tue, 1 Jul 2003 04:22:32 -0700 (PDT) (envelope-from nsyracus@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 HAA06867; Tue, 1 Jul 2003 07:22:29 -0400 (EDT) Message-Id: <200307011122.HAA06867@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-sasl@imc.org, ietf-http-wg@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-nystrom-http-sasl-07.txt Date: Tue, 01 Jul 2003 07:22:28 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SASL in HTTP/1.1 Author(s) : M. Nystrom, A. Melnikov Filename : draft-nystrom-http-sasl-07.txt Pages : 33 Date : 2003-6-30 This memo suggest the use of SASL [RFC2222] as a framework to enable the use of strong authentication mechanisms in http/1.1 [RFC2616], and defines one approach to accomplish this. Please send comments on this document to the relevant mailing lists, e.g. ietf-sasl@imc.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-07.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-nystrom-http-sasl-07.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-nystrom-http-sasl-07.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-6-30151300.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nystrom-http-sasl-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-nystrom-http-sasl-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-30151300.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Tue Jul 1 04:23:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61BNnFK046726 for ; Tue, 1 Jul 2003 04:23:49 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61BNnDl046725 for ietf-sasl-bks; Tue, 1 Jul 2003 04:23:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61BNmFK046720 for ; Tue, 1 Jul 2003 04:23:48 -0700 (PDT) (envelope-from nsyracus@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 HAA07324; Tue, 1 Jul 2003 07:23:45 -0400 (EDT) Message-Id: <200307011123.HAA07324@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-01.txt Date: Tue, 01 Jul 2003 07:23:45 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-01.txt Pages : 18 Date : 2003-6-30 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-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-rfc2222bis-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-rfc2222bis-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-6-30151543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-30151543.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Tue Jul 1 07:02:06 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61E26FK055184 for ; Tue, 1 Jul 2003 07:02:06 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61E240x055183 for ietf-sasl-bks; Tue, 1 Jul 2003 07:02:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61E23FK055174 for ; Tue, 1 Jul 2003 07:02:03 -0700 (PDT) (envelope-from leg@andrew.cmu.edu) Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.12.9/8.12.6) with ESMTP id h61E1sXM006527; Tue, 1 Jul 2003 07:01:54 -0700 Received: from mirapoint.corp.google.com (IDENT:mirapoint@mirapoint.corp.google.com [10.32.0.80]) by moma.corp.google.com (8.12.9/8.12.3) with ESMTP id h61E1sff029572; Tue, 1 Jul 2003 07:01:54 -0700 Received: from andrew.cmu.edu (dunbar.corp.google.com [10.2.2.110]) by mirapoint.corp.google.com (Mirapoint Messaging Server MOS 3.3.5-GR) with ESMTP id ABT15494 (AUTH leg); Tue, 1 Jul 2003 07:01:53 -0700 (PDT) Message-ID: <3F019450.8020808@andrew.cmu.edu> Date: Tue, 01 Jul 2003 10:01:52 -0400 From: Larry Greenfield User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Guenther CC: Rob Siemborski , Greg Hudson , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <200307010435.h614Zgf12987@katroo.Sendmail.COM> In-Reply-To: <200307010435.h614Zgf12987@katroo.Sendmail.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: >Rob Siemborski writes: >... > > >>This works, until an application is running using an incompatible >>threading API (see Larry's answer to my earlier question). >> >> >I knew I should have replied to Larry's answer. I find his example >unconvincing. He has suggested that there may exist a cooperative >threading library running on a system that has a system level threading >implementation and that intercepts blocking I/O calls (i.e., supplies >symbols like connect(), read(), etc) such that it intercepts the calls >of unmodified libraries, but that *doesn't* intercept calls to the >system's threading primitives. (If that's not what you're suggesting, >Larry, please correct me.) > This appears to be an accurate description of the GNU Pth library using the "hard system call mapping". (I base this off of the documentation and not first hand experience.) Pth is a popular and frequently used threading library. Larry From owner-ietf-sasl Tue Jul 1 07:12:54 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61ECsFK055913 for ; Tue, 1 Jul 2003 07:12:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61ECsgC055912 for ietf-sasl-bks; Tue, 1 Jul 2003 07:12:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61ECqFK055906 for ; Tue, 1 Jul 2003 07:12:52 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from BBOARD.andrew.cmu.edu (BBOARD.andrew.cmu.edu [128.2.10.89]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h61ECquO006725; Tue, 1 Jul 2003 10:12:52 -0400 Date: Tue, 1 Jul 2003 10:12:53 -0400 (EDT) From: Rob Siemborski To: Greg Hudson cc: ietf-sasl@imc.org Subject: Re: Using SASL C API from a library In-Reply-To: <1057032466.12524.317.camel@error-messages.mit.edu> Message-ID: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.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 Tue, 1 Jul 2003, Greg Hudson wrote: > > Unless I am misremembering, this is basically what we discussed in San > > Francisco (I thought I had mentioned that). > > (The minutes do not appear to document any discussion of the SASL C API, > incidentally.) Since its not a charter item, it wasn't discussed in the formal WG meeting. I think Alexey has notes from when a few of us sat around discussing it though. > Previously, you said "it can be solved by not using global callbacks > except in the outermost application," which is very different from "not > using global callbacks at all." > > > Note that this is difficult for situations such as the getopt callback > > where path information to loadable modules (or similar information that is > > requried for the library to initialize) may need to be obtained. > > There is really no limit to the number of awful things you could justify > putting into the API if you want to satisfy every possible foible of a > back-end library. [snip] You don't need to satisfy every possible one, but let's at least try to anticipate reasonable desires of the implementors. > So, unless you can demonstrate a present practical issue, I don't think > this argument is even vaguely compelling. Kerberos mechanisms need a path to a srvtab or keytab. Perhaps shared secret mechanisms need a path to a database of shared secrets. Perhaps one of the worse examples (though one of the most useful) is a list of mechanisms to limit what the library advertises. The good news here is that most of these are (or can be made to be) connection-context specific. Ones that potentially need to be supported by a global getopt callback really significantly fewer. > Franky, the getopt callback is a great big hole in the spec for > unspecified behavior (both mechanism-specific and > implementation-specific), since there is no standardization of what the > options mean. Presumably the idea is that you would provide the answers > from a configuration file or from command-line options, giving a sort of > direct communications channel between the user and the SASL library or > specific mechanism. That may sound attractive to implementors, but it's > a totally unacceptable idea, because it's impossible to document such a > config file or command-line syntax without knowing the intimate (and > version-specific) details of your SASL implementation, and because it's > impossible to provide reasonable answers in a situation where a config > file or command line doesn't make sense. The application doesn't have to understand the options its handing to the library, only the user does. And the user can have access to implementation-specific information about the library. Sure, the library can also just access a configuration file to get the information it needs, but then how does the user supply the path the the configuration file? I'm quite certain that having a fixed path to a configuration file isn't what users are looking for. And being able to combine SASL options with application options in one place is a usability improvement. Implementations of the SASL API will require configuration options to function properly, we shouldn't deny them a reasonable way to get that information in a standard way, even if the information itself is implementation dependent. -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 Tue Jul 1 08:27:29 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61FRTFK060498 for ; Tue, 1 Jul 2003 08:27:29 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61FRTD9060497 for ietf-sasl-bks; Tue, 1 Jul 2003 08:27:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61FRSFK060489 for ; Tue, 1 Jul 2003 08:27:28 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h61FRS9W001128; Tue, 1 Jul 2003 11:27:28 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h61FRRjO013920; Tue, 1 Jul 2003 11:27:27 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h61FRRU8006774; Tue, 1 Jul 2003 11:27:27 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h61FRQwU023364; Tue, 1 Jul 2003 11:27:26 -0400 Subject: Re: Using SASL C API from a library From: Greg Hudson To: Rob Siemborski Cc: ietf-sasl@imc.org In-Reply-To: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057073245.12524.334.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 01 Jul 2003 11:27:26 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2003-07-01 at 10:12, Rob Siemborski wrote: > > So, unless you can demonstrate a present practical issue, I don't think > > this argument is even vaguely compelling. > The good news here is that most of these are (or can be made to be) > connection-context specific. Ones that potentially need to be supported > by a global getopt callback really significantly fewer. Certainly it should be possible for krb5, since krb5 does not use global state. (It also does not allow the caller to pass a path to find krb5.conf.) > Sure, the library can also just access a configuration file to get the > information it needs, but then how does the user supply the path the the > configuration file? I'm quite certain that having a fixed path to a > configuration file isn't what users are looking for. I believe this is argument from fantasy. I don't think there's any back-end mechanism library which asks for this kind of information from the calling code. They all uses fixed paths, possibly overridden by environment variables which the calling code is not expected to tamper with. > And being able to combine SASL options with application options in one > place is a usability improvement. Options required for a SASL library itself should be nailed down by the spec or not subject to configuration by the caller. (The plugin dir, for instance, should be found in a fixed location or via an environment variable; there's no reason for SASL to introduce a completely new override mechanism.) > Implementations of the SASL API will require configuration options to > function properly, we shouldn't deny them a reasonable way to get that > information in a standard way, even if the information itself is > implementation dependent. Once again, you've made an argument which (I believe) no other standardized API makes, and provided no specific examples to back it up. From owner-ietf-sasl Wed Jul 2 09:36:39 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62GadFK068828 for ; Wed, 2 Jul 2003 09:36:39 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62GadEW068827 for ietf-sasl-bks; Wed, 2 Jul 2003 09:36:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62GacFK068822 for ; Wed, 2 Jul 2003 09:36:38 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 09646151582; Wed, 2 Jul 2003 12:36:25 -0400 (EDT) To: ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> From: Sam Hartman Date: Wed, 02 Jul 2003 12:36:25 -0400 In-Reply-To: (Rob Siemborski's message of "Mon, 30 Jun 2003 14:50:44 -0400 (EDT)") 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: >>>>> "Rob" == Rob Siemborski writes: Rob> On Sun, 29 Jun 2003, Greg Hudson wrote: >> It seems like a bizarre argument, especially when Unix systems >> converged on the POSIX threads API years and years ago. Rob> Solaris has a non-pthreads threading API. There's no reason Rob> the SASL C API should dictate what threading API to use. It's my understanding that at least in recent Solaris versions, the locks between this API and the pthreads API are compatible. Please correct me if I'm wrong. From owner-ietf-sasl Wed Jul 2 13:34:53 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KYqFK082655 for ; Wed, 2 Jul 2003 13:34:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62KYqUx082654 for ietf-sasl-bks; Wed, 2 Jul 2003 13:34:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KYFFK082613 for ; Wed, 2 Jul 2003 13:34:28 -0700 (PDT) (envelope-from nsyracus@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 QAA13327; Wed, 2 Jul 2003 16:34:12 -0400 (EDT) Message-Id: <200307022034.QAA13327@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-anon-02.txt Date: Wed, 02 Jul 2003 16:34:12 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The Anonymous SASL Mechanism Author(s) : K. Zeilenga Filename : draft-ietf-sasl-anon-02.txt Pages : 9 Date : 2003-7-2 It is common practice on the Internet to permit anonymous access to various services. Traditionally, this has been done with a plain text password mechanism using 'anonymous' as the user name and optional trace information, such as an email address, as the password. As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the Simple Authentication and Security Layer (SASL) framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-anon-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-anon-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-anon-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2162000.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-anon-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-anon-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2162000.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Wed Jul 2 13:34:46 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KYkFK082645 for ; Wed, 2 Jul 2003 13:34:46 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62KYkVA082644 for ietf-sasl-bks; Wed, 2 Jul 2003 13:34:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KYOFK082617 for ; Wed, 2 Jul 2003 13:34:30 -0700 (PDT) (envelope-from nsyracus@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 QAA13350; Wed, 2 Jul 2003 16:34:17 -0400 (EDT) Message-Id: <200307022034.QAA13350@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-plain-02.txt Date: Wed, 02 Jul 2003 16:34:16 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The Plain SASL Mechanism Author(s) : K. Zeilenga Filename : draft-ietf-sasl-plain-02.txt Pages : 8 Date : 2003-7-2 This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols which lack a simple password authentication command. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-plain-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-plain-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-plain-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2162011.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-plain-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-plain-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2162011.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Wed Jul 2 13:35:45 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KZjFK082695 for ; Wed, 2 Jul 2003 13:35:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62KZj6g082694 for ietf-sasl-bks; Wed, 2 Jul 2003 13:35:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KYBFK082612 for ; Wed, 2 Jul 2003 13:34:15 -0700 (PDT) (envelope-from nsyracus@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 QAA13309; Wed, 2 Jul 2003 16:34:07 -0400 (EDT) Message-Id: <200307022034.QAA13309@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-saslprep-03.txt Date: Wed, 02 Jul 2003 16:34:06 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : SASLprep: Stringprep profile for user names and passwords Author(s) : K. Zeilenga Filename : draft-ietf-sasl-saslprep-03.txt Pages : 6 Date : 2003-7-2 This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the 'SASLprep' 'stringprep' profile to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging user names and/or passwords. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-03.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-saslprep-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-saslprep-03.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-7-2161947.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-saslprep-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-saslprep-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161947.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Wed Jul 2 18:53:24 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h631rOFK097002 for ; Wed, 2 Jul 2003 18:53:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h631rO8j097001 for ietf-sasl-bks; Wed, 2 Jul 2003 18:53:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h631rOFK096996 for ; Wed, 2 Jul 2003 18:53:24 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust22.tnt101.lnd4.gbr.da.uu.net [213.116.50.22]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h631utV31115; Wed, 2 Jul 2003 19:56:56 -0600 Message-ID: <3F037BD6.AC4E6681@isode.com> Date: Wed, 02 Jul 2003 18:41:59 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg Hudson CC: Rob Siemborski , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greg Hudson wrote: > > Sure, the library can also just access a configuration file to get the > > information it needs, but then how does the user supply the path the the > > configuration file? I'm quite certain that having a fixed path to a > > configuration file isn't what users are looking for. > > I believe this is argument from fantasy. I don't think there's any > back-end mechanism library which asks for this kind of information from > the calling code. They all uses fixed paths, possibly overridden by > environment variables which the calling code is not expected to tamper > with. > > And being able to combine SASL options with application options in one > > place is a usability improvement. > > Options required for a SASL library itself should be nailed down by the > spec or not subject to configuration by the caller. (The plugin dir, > for instance, should be found in a fixed location or via an environment > variable; there's no reason for SASL to introduce a completely new > override mechanism.) Oh, please. What if my application wants to use a fixes path, but not the one hardcoded in the SASL library? Plus hardcoded paths don't work on certain OSes (e.g. Windows). Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Wed Jul 2 18:53:10 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h631rAFK096986 for ; Wed, 2 Jul 2003 18:53:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h631rAKH096985 for ietf-sasl-bks; Wed, 2 Jul 2003 18:53:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h631r9FK096980 for ; Wed, 2 Jul 2003 18:53:09 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust22.tnt101.lnd4.gbr.da.uu.net [213.116.50.22]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h631udV31109; Wed, 2 Jul 2003 19:56:41 -0600 Message-ID: <3F037AF4.7919F21C@isode.com> Date: Wed, 02 Jul 2003 18:38:12 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Josefsson CC: ietf-sasl@imc.org Subject: Re: Comments on the SASL C API References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon Josefsson wrote: > ... I've added some clarification about multiple SASL tokens in sasl_decode as described by Larry. > Extension: > Here is a writeup on an idea I have received. It might cause some > complications and likely needs more pondering. However, if the > rationale for adding this makes sense to you, I'd appreciate if you > spent the time incorporating the functions. If you are familiar with > the GSS-API, compare this to the gss_export_sec_context and > gss_import_sec_context functions that were added to GSS-API version 2 > (see RFC 2744). I like the idea and had though about something similar myself. The question is if this belong to the base SASL API document or should this be an extension. I would like to hear what other people think about adding this. > 5.2. Exporting and importing security layer state > > Some application environments wishes to separate the initial and > short authentication step from the potentially long lived > application step, where the application uses sasl_encode() and > sasl_decode() to transfer application data. This separation may > be between processes (separation across hosts is more > complicated, as the security layer state is often dependent on > the host address, but still conceivable). The reason for such > separation may be to guarantee that long-term secrets (e.g., > passwords) cannot be recovered by compromising the application > that handles existing session. > > The functions defined in this section allows the application to > export the security layer state associated with a session as an > opaque character string, and later import the opaque character > string. The opaque state typically contains an encryption key, > initialization vectors, what encryption algorithm to use, packet > number etc. > > 5.2.1. sasl_export_security_layer_state function > > Arguments: > sasl_conn_t *conn, > const char **state, > unsigned int *statelen > > Results: > SASL_OK -- Success > SASL_NOTDONE -- Security layer negotiation not finished > > This function exports the security layer state required to > implement the sasl_encode() and sasl_decode() functions after > the state has been imported. The security layer state is an > opaque data string. The state and statelen are filled in with > the opaque state data and its length respectively. If the > security layer negotiation has not finished, SASL_NOTDONE is > returned. After calling this function, the application should > treat the SASL session as concluded and call sasl_dispose(). In > particular, the application MUST NOT call sasl_encode() or > sasl_decode() [XXX sasl_dencode should simply return a error > code when it happens]. The state data is only valid until a > call to sasl_dispose(), and should be copied before calling > sasl_dipose() if necessary. > > 5.2.2. sasl_import_security_layer_state function > > Arguments: > const char *state, > unsigned int statelen > sasl_conn_t **conn, > > Results: > SASL_OK -- Success > SASL_BADPARAM -- Invalid parameter supplied > > This function create a SASL session, for use with sasl_encode(), > sasl_decode() and sasl_dispose() only, from the given security > layer state. The security layer state is an opaque data string, > as returned from sasl_export_security_layer_state(). Cheers, Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Wed Jul 2 18:53:35 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h631rYFK097014 for ; Wed, 2 Jul 2003 18:53:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h631rYnZ097013 for ietf-sasl-bks; Wed, 2 Jul 2003 18:53:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h631rYFK097008 for ; Wed, 2 Jul 2003 18:53:34 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust22.tnt101.lnd4.gbr.da.uu.net [213.116.50.22]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h631vAV31120; Wed, 2 Jul 2003 19:57:11 -0600 Message-ID: <3F037D21.D883D566@isode.com> Date: Wed, 02 Jul 2003 18:47:29 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Siemborski CC: ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: > > Since people have grown silent on the topic, I'll note that no excuse > > has been given for the global callbacks structure, and no answer has > > been given to my argument that library calls to the SASL C API could > > accidentally trigger invocations of the application's global callbacks > > no matter what the library does to guard against this possibility. If > > transition for users of Cyrus SASL is the only concern, then the API > > spec can preserve the parameter as a dummy and mandate that all callers > > must pass NULL, as has been done in Unix with gettimeofday() and the > > timezone parameter. > > Unless I am misremembering, this is basically what we discussed in San > Francisco (I thought I had mentioned that). Yes, this is in my notes. More specifically: 1). Init problem: deprecatate global callbacks. If global callbacks are provided multiple times, this is implementation dependent. 2). Make appname setprop/getprop appname must be NULL in sasl_server_init, if it is called from a library. > Note that this is difficult for situations such as the getopt callback, > where path information to loadable modules (or similar information that is > requried for the library to initialize) may need to be obtained. In this > case (since it is part of the one-time library startup) the application > would need to supply a getopt callback. Since its one-time startup state, > your library couldn't change it if it wanted to. So, where this discussion leaves us? Should I change the document to say that global callbacks must be NULL, except for maybe the getopt callback? Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Wed Jul 2 19:05:09 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63259FK098063 for ; Wed, 2 Jul 2003 19:05:09 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h632593O098062 for ietf-sasl-bks; Wed, 2 Jul 2003 19:05:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63257FK098057 for ; Wed, 2 Jul 2003 19:05:08 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h63257QU012768; Wed, 2 Jul 2003 22:05:07 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h63256pP012527; Wed, 2 Jul 2003 22:05:07 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h63256FJ021029; Wed, 2 Jul 2003 22:05:06 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h63254l8025028; Wed, 2 Jul 2003 22:05:04 -0400 Subject: Re: Using SASL C API from a library From: Greg Hudson To: Alexey Melnikov Cc: ietf-sasl@imc.org In-Reply-To: <3F037BD6.AC4E6681@isode.com> References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057197903.12524.401.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 02 Jul 2003 22:05:04 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 2003-07-02 at 20:41, Alexey Melnikov wrote: > > Options required for a SASL library itself should be nailed down by the > > spec or not subject to configuration by the caller. (The plugin dir, > > for instance, should be found in a fixed location or via an environment > > variable; there's no reason for SASL to introduce a completely new > > override mechanism.) > > Oh, please. What if my application wants to use a fixes path, but not the one > hardcoded in the SASL library? > > Plus hardcoded paths don't work on certain OSes (e.g. Windows). Why would you ever write an application which cares, more than any other application, where a SASL library looks for its plugin directory? Every caller of the SASL library should be in the same position here. Which means the library needs to be able to find its plugins without help from the calling code. Whether that means a fixed path, an environment variable, the registry, or whatever else is up to the library, but asking the calling code to provide that information is of no help. But let's say I'm wrong, and there really is some good reason why the calling code should be helping out. And let's also say that this reason isn't good enough to make the plugin directory part of the standard SASL C API. What value is there in half-standardizing the interface through which the library gets this information? If some application needs this non-standard functionality and therefore can only use (let's say) the Cyrus implementation, then the Cyrus implementation can add its own non-standard function to specify the plugin directory. From owner-ietf-sasl Wed Jul 2 20:30:09 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h633U9FK000923 for ; Wed, 2 Jul 2003 20:30:09 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h633U8Y1000922 for ietf-sasl-bks; Wed, 2 Jul 2003 20:30:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h633U7FK000917 for ; Wed, 2 Jul 2003 20:30:07 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h633U6ST018367 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 3 Jul 2003 05:30:07 +0200 To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Comments on the SASL C API References: <3F037AF4.7919F21C@isode.com> From: Simon Josefsson X-Payment: hashcash 1.2 0:030703:Alexey.Melnikov@isode.com:eaeec8eca266056f X-Hashcash: 0:030703:Alexey.Melnikov@isode.com:eaeec8eca266056f X-Payment: hashcash 1.2 0:030703:ietf-sasl@imc.org:b8615009abdb22a5 X-Hashcash: 0:030703:ietf-sasl@imc.org:b8615009abdb22a5 Date: Thu, 03 Jul 2003 05:30:06 +0200 In-Reply-To: <3F037AF4.7919F21C@isode.com> (Alexey Melnikov's message of "Wed, 02 Jul 2003 18:38:12 -0600") 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 X-Spam-Status: No, hits=-29.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > I've added some clarification about multiple SASL tokens in sasl_decode as > described by Larry. Thank you, and also to Greg and Larry who provided insight. The problem had a simple solution, but it wasn't really obvious [to me], so additional text would not hurt. Perhaps it can even be useful to application writers, so they know sasl_decode() could return data that is the concatenation of output from more than one call to sasl_encode(). It appears that this could affect the choice of buffer sizes. From owner-ietf-sasl Thu Jul 3 06:51:38 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63DpbFK058744 for ; Thu, 3 Jul 2003 06:51:37 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63Dpb9q058743 for ietf-sasl-bks; Thu, 3 Jul 2003 06:51:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63DpaFK058738 for ; Thu, 3 Jul 2003 06:51:36 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h63DpZuO006317; Thu, 3 Jul 2003 09:51:35 -0400 Date: Thu, 3 Jul 2003 09:51:35 -0400 (EDT) From: Rob Siemborski To: Greg Hudson cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library In-Reply-To: <1057197903.12524.401.camel@error-messages.mit.edu> Message-ID: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.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 Wed, 2 Jul 2003, Greg Hudson wrote: > But let's say I'm wrong, and there really is some good reason why the > calling code should be helping out. And let's also say that this reason > isn't good enough to make the plugin directory part of the standard SASL > C API. What value is there in half-standardizing the interface through > which the library gets this information? If some application needs this > non-standard functionality and therefore can only use (let's say) the > Cyrus implementation, then the Cyrus implementation can add its own > non-standard function to specify the plugin directory. Are you saying its better to have NO standard way to get configuration information into the library fromt he application? Thus, if I want an application to work with two types of libraries, I have to provide (in hard code) perhaps a callback for SASL_NONSTANARD_CB_PATHNAME and SASL_NONSTANDARD_CB_PATH_TO_PLUGINS just to work with two implementation? Worse: what if these two implementations define the same values for these two callbacks! The getopt callback supplys a standard way to get this information from the application. Since presumably the application is looking up this information in its own config files, the user can read the documentation for their SASL implementation and decide if they need to set the SASL option "pathname" or "path_to_plugins". This can be done without needing to change the code to the application. -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 Thu Jul 3 08:47:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63Flwqt000231 for ; Thu, 3 Jul 2003 08:47:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63Flw5N000230 for ietf-sasl-bks; Thu, 3 Jul 2003 08:47:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63Floqt000223 for ; Thu, 3 Jul 2003 08:47:57 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust128.tnt24.lnd4.gbr.da.uu.net [62.188.151.128]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h63FkmV04797; Thu, 3 Jul 2003 09:46:51 -0600 Message-ID: <3F043077.BD141F4F@isode.com> Date: Thu, 03 Jul 2003 07:32:39 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Josefsson CC: ietf-sasl@imc.org Subject: Re: Comments on the SASL C API References: <3F037AF4.7919F21C@isode.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon Josefsson wrote: > Alexey Melnikov writes: > > > I've added some clarification about multiple SASL tokens in sasl_decode as > > described by Larry. > > Thank you, and also to Greg and Larry who provided insight. The > problem had a simple solution, but it wasn't really obvious [to me], > so additional text would not hurt. Perhaps it can even be useful to > application writers, so they know sasl_decode() could return data that > is the concatenation of output from more than one call to > sasl_encode(). It appears that this could affect the choice of buffer > sizes. sasl_decode allocates or returns own buffer, so the caller shouldn't worry about buffer sizes. Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Thu Jul 3 10:04:32 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63H4Vqt006936 for ; Thu, 3 Jul 2003 10:04:31 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63H4VqB006935 for ietf-sasl-bks; Thu, 3 Jul 2003 10:04:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63H4Uqt006929 for ; Thu, 3 Jul 2003 10:04:31 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h63H4TmK015407; Thu, 3 Jul 2003 13:04:29 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h63H4SEk025075; Thu, 3 Jul 2003 13:04:28 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h63H4SFJ009148; Thu, 3 Jul 2003 13:04:28 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h63H4RcJ025661; Thu, 3 Jul 2003 13:04:27 -0400 Subject: Re: Using SASL C API from a library From: Greg Hudson To: Rob Siemborski Cc: ietf-sasl@imc.org In-Reply-To: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057251866.12524.430.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 03 Jul 2003 13:04:27 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-07-03 at 09:51, Rob Siemborski wrote: > Are you saying its better to have NO standard way to get configuration > information into the library fromt he application? Absolutely. The vast majority of APIs contain no such mechanism, because a library should be able to do its job without creating such a mechanism. If for some reason the library needs configuration, it can get it via its own configuration files, which it can find through mechanisms not involving the calling code (fixed paths, environment variables, the registry, etc.). The only exception class tends to be gui toolkits, which usually want to take over the command line by accepting and modifying argc and argv. I'm ambivalent about this practice (it makes it harder to document the command-line syntax of programs using the gui toolkit, but it's hard to imagine doing without it given the variety of standard command-line arguments affecting the toolkit), but it's not terribly onerous because a GUI toolkit tends to dominate the scope and structure of an application. Not so with a SASL library. > Thus, if I want an > application to work with two types of libraries, I have to provide (in > hard code) perhaps a callback for SASL_NONSTANARD_CB_PATHNAME and > SASL_NONSTANDARD_CB_PATH_TO_PLUGINS just to work with two implementation? If we are talking about an application providing this information for its own reasons, then it's already sunk; the SASL API says nothing about plugin paths, you don't know what option name would be involved, and the implementation might not even use plugins. (And of course, if the application is providing such information for its own reasons, it probably cares about the back-end plugin interface, which isn't specified at all.) But, of course, the specifiers are not envisioning an application providing this information for its own reasons; they are envisioning an application blindly (no stigma here) passing along user configuration, as reflected here: > The getopt callback supplys a standard way to get this information from > the application. Since presumably the application is looking up this > information in its own config files, the user can read the documentation > for their SASL implementation and decide if they need to set the SASL > option "pathname" or "path_to_plugins". This can be done without needing > to change the code to the application. We're going around in circles on this point. I'll skip the part where I argue against this idea at the end of and go to the part where you respond in with (among discussions of fixed paths versus other ways of finding a config file, which we've also talked about at length): And being able to combine SASL options with application options in one place is a usability improvement. which is another puzzling argument. Most discussion of usability revolves around GUI interfaces, and it is impossible to create a non-degenerate GUI configuration interface for options you know nothing about. The best you can do is provide a registry-like interface where the user can manipulate key-value pairs, which is only one step away from editing text files. But even if we're talking about usability among the tiny (percentagewise) population of users who are comfortable editing configuration files, I don't see the benefit. Why would I want to have a single configuration whose meaning is split over two or more different pieces of documentation? Wouldn't I like my configuration files to have nicely commented templates? (That would be logistically difficult for configuration files which span abstraction barriers like you envision.) And if I want to change where (say) Cyrus SASL looks for its plugins, why would I want to have to do that for every application which uses Cyrus SASL, instead of doing it in one place? From owner-ietf-sasl Thu Jul 3 10:15:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63HFXqt007884 for ; Thu, 3 Jul 2003 10:15:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63HFXIp007883 for ietf-sasl-bks; Thu, 3 Jul 2003 10:15:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63HFWqt007877 for ; Thu, 3 Jul 2003 10:15:32 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h63HFWuO019390; Thu, 3 Jul 2003 13:15:32 -0400 Date: Thu, 3 Jul 2003 13:15:31 -0400 (EDT) From: Rob Siemborski To: Greg Hudson cc: ietf-sasl@imc.org Subject: Re: Using SASL C API from a library In-Reply-To: <1057251866.12524.430.camel@error-messages.mit.edu> Message-ID: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.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 Thu, 3 Jul 2003, Greg Hudson wrote: > And if I want to change where (say) Cyrus SASL looks for its plugins, > why would I want to have to do that for every application which uses > Cyrus SASL, instead of doing it in one place? Nothing prevents the library from having defaults, or looking at environment variables, or reading from /dev/random to gain the information otherwise provided by getopt in other ways. However, in your scenario all the applications running on a system need to share the same global configuration with no possibility of making application-specific changes. Which really isn't acceptable. -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 Thu Jul 3 10:25:32 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63HPWqt008221 for ; Thu, 3 Jul 2003 10:25:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63HPW45008220 for ietf-sasl-bks; Thu, 3 Jul 2003 10:25:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63HPVqt008212 for ; Thu, 3 Jul 2003 10:25:31 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h63HPR2A004231; Thu, 3 Jul 2003 13:25:30 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h63HKREk026630; Thu, 3 Jul 2003 13:20:28 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h63HKRFJ009668; Thu, 3 Jul 2003 13:20:27 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h63HKQ57025753; Thu, 3 Jul 2003 13:20:26 -0400 Subject: Re: Using SASL C API from a library From: Greg Hudson To: Rob Siemborski Cc: ietf-sasl@imc.org In-Reply-To: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057252825.12524.435.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 03 Jul 2003 13:20:26 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-07-03 at 13:15, Rob Siemborski wrote: > However, in your scenario all the applications running on a system need to > share the same global configuration with no possibility of making > application-specific changes. Which really isn't acceptable. Why not? There is no application-specific configuration for krb5, or for the resolver, or for a host of other libraries. (You can, of course, hack it up using environment variables and alternate config files, but people rarely seem to.) If you actually can come up with a practical reason to have application-specific configuration for a SASL library (a concept which doesn't make a lot of sense when SASL is being driven from another library), then it is *still* better to handle this from a SASL-specific configuration file, using options keyed off the application name, because then it's possible to write documentation and GUI tools which understand everything about the config file, unlike in your scheme. From owner-ietf-sasl Thu Jul 3 11:35:04 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63IZ4qt013617 for ; Thu, 3 Jul 2003 11:35:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63IZ4mS013616 for ietf-sasl-bks; Thu, 3 Jul 2003 11:35:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63IZ3qt013611 for ; Thu, 3 Jul 2003 11:35:03 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h63IZ3uO023946; Thu, 3 Jul 2003 14:35:03 -0400 Date: Thu, 3 Jul 2003 14:35:02 -0400 (EDT) From: Rob Siemborski To: ietf-sasl@imc.org cc: kurt@OpenLDAP.org Subject: Re: I-D ACTION:draft-ietf-sasl-anon-02.txt In-Reply-To: <200307022034.QAA13327@ietf.org> Message-ID: References: <200307022034.QAA13327@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 Wed, 2 Jul 2003 Internet-Drafts@ietf.org wrote: > Title : The Anonymous SASL Mechanism > Author(s) : K. Zeilenga > Filename : draft-ietf-sasl-anon-02.txt >> ...not part of SASL itself. Newer profiles of SASL will include the client message with the AUTHENTICATE command itself so the extra round trip below (the server response with an empty "+ ") can be eliminated. << Seems to indicate a requirement on new SASL profiles, which is outside of the scope of the document. However, it is reasonable to add some clarification that the extra round trip is an artifact of the IMAP profile. How about something more like: ...not part of SASL itself. Additionally, protocols with SASL profiles permitting an initial client response will be able to avoid the extra round trip below (the server response with an empty "+ "). -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 Thu Jul 3 15:29:47 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63MTlqt025102 for ; Thu, 3 Jul 2003 15:29:47 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63MTlte025101 for ietf-sasl-bks; Thu, 3 Jul 2003 15:29:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63MTkqt025096 for ; Thu, 3 Jul 2003 15:29:46 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust9.tnt14.lnd4.gbr.da.uu.net [62.188.143.9]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h63MXFV08159; Thu, 3 Jul 2003 16:33:16 -0600 Message-ID: <3F04ADD2.31E16D8B@isode.com> Date: Thu, 03 Jul 2003 16:27:30 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg Hudson CC: Rob Siemborski , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greg Hudson wrote: > On Thu, 2003-07-03 at 09:51, Rob Siemborski wrote: > > Are you saying its better to have NO standard way to get configuration > > information into the library fromt he application? > > Absolutely. The vast majority of APIs contain no such mechanism, > because a library should be able to do its job without creating such a > mechanism. If for some reason the library needs configuration, it can > get it via its own configuration files, which it can find through > mechanisms not involving the calling code (fixed paths, environment > variables, the registry, etc.). I am afraid I disagree. Centralizing all configuration for an application in one place might be a good (and required) thing. > The only exception class tends to be gui toolkits, which usually want to > take over the command line by accepting and modifying argc and argv. > I'm ambivalent about this practice (it makes it harder to document the > command-line syntax of programs using the gui toolkit, but it's hard to > imagine doing without it given the variety of standard command-line > arguments affecting the toolkit), but it's not terribly onerous because > a GUI toolkit tends to dominate the scope and structure of an > application. Not so with a SASL library. > > > Thus, if I want an > > application to work with two types of libraries, I have to provide (in > > hard code) perhaps a callback for SASL_NONSTANARD_CB_PATHNAME and > > SASL_NONSTANDARD_CB_PATH_TO_PLUGINS just to work with two implementation? > > If we are talking about an application providing this information for > its own reasons, then it's already sunk; the SASL API says nothing about > plugin paths, you don't know what option name would be involved, and the > implementation might not even use plugins. (And of course, if the > application is providing such information for its own reasons, it > probably cares about the back-end plugin interface, which isn't > specified at all.) > > But, of course, the specifiers are not envisioning an application > providing this information for its own reasons; they are envisioning an > application blindly (no stigma here) passing along user configuration, > as reflected here: Ok people. I am afraid we are starting a religious war at this point and this is not going to do us any good. So, how about making some constructive suggestions. How about the following: 1). libraries MUST NOT specify callbacks when calling sasl_client_init/sasl_server_init. Global callbacks are thus deprecated. 2). a new function is added to set getopt callback. An application that doesn't care about getopt, will not call this function. If this callback is not set, the SASL library will use reasonable defaults or get the required information from own config file/environment/registry/whatever. 3). one of the getopt options is a plugin directory. If the application doesn't care, its getopt callback will fail to return the value for this option. The SASL library will choose a reasonable default in this case. If the SASL library doesn't support plugins, it will not care about this option. I believe this is how it works now anyway (except for new function for setting getopt). Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Thu Jul 3 15:44:10 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63MiAqt026210 for ; Thu, 3 Jul 2003 15:44:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63MiAs4026209 for ietf-sasl-bks; Thu, 3 Jul 2003 15:44:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63Mi8qt026203 for ; Thu, 3 Jul 2003 15:44:09 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h63MiAuO031643; Thu, 3 Jul 2003 18:44:10 -0400 Date: Thu, 3 Jul 2003 18:44:10 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: Greg Hudson , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library In-Reply-To: <3F04ADD2.31E16D8B@isode.com> Message-ID: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 3 Jul 2003, Alexey Melnikov wrote: > Ok people. I am afraid we are starting a religious war at this point and > this is not going to do us any good. I agree. > So, how about making some constructive suggestions. How about the following: > 1). libraries MUST NOT specify callbacks when calling > sasl_client_init/sasl_server_init. > Global callbacks are thus deprecated. > > 2). a new function is added to set getopt callback. An application that > doesn't care about getopt, will not call this function. If this callback > is not set, the SASL library will use reasonable defaults or get the > required information from own config file/environment/registry/whatever. > > 3). one of the getopt options is a plugin directory. If the application doesn't > care, its getopt callback will fail to return the value for this option. The > SASL library will choose a reasonable default in this case. If the SASL library > doesn't support plugins, it will not care about this option. This is worse than the global callbacks scenario with libraries forbidden from setting global callbaks, since in this situation a libary can call the magic new function to set the getopt() callback. I don't see how this is better than allowing a getopt() callback to be set by the application, but not by libraries in the call to sasl_xxx_init(). Even if we forbid libraries from calling this new function, the situation is worse than allowing applications to set a getopt callback in their call to sasl_xxx_init(), as it requires changes from current practice. > I believe this is how it works now anyway (except for new function for setting > getopt). Not quite true, this requires standardizing the name of an option, as well. -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 Thu Jul 3 15:43:01 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63Mh1qt026128 for ; Thu, 3 Jul 2003 15:43:01 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63Mh1jd026127 for ietf-sasl-bks; Thu, 3 Jul 2003 15:43:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63Mh0qt026122 for ; Thu, 3 Jul 2003 15:43:00 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h63Mh16i028898; Thu, 3 Jul 2003 18:43:01 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h63Mh0qM022391; Thu, 3 Jul 2003 18:43:01 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h63MgvFJ018404; Thu, 3 Jul 2003 18:42:58 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h63MgunK026152; Thu, 3 Jul 2003 18:42:56 -0400 Subject: Re: Using SASL C API from a library From: Greg Hudson To: Alexey Melnikov Cc: ietf-sasl@imc.org In-Reply-To: <3F04ADD2.31E16D8B@isode.com> References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057272175.12524.444.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 03 Jul 2003 18:42:56 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-07-03 at 18:27, Alexey Melnikov wrote: > So, how about making some constructive suggestions. How about the following: > 1). libraries MUST NOT specify callbacks when calling > sasl_client_init/sasl_server_init. > Global callbacks are thus deprecated. You seem to leave open the question of whether applications are allowed to specify callbacks. Was that intentional? (As I've mentioned before, if applications are allowed to set global callbacks, then a library using SASL cannot guard against accidentally triggering the application global callbacks.) > 2). a new function is added to set getopt callback. An application that doesn't > care about getopt, will not call this function. Well, as everybody knows, my religion does not include such a device, but global state is generally not burdensome as long as it's (completely) optional. So I won't scream and yell about it. From owner-ietf-sasl Fri Jul 4 05:18:25 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64CIPqt085751 for ; Fri, 4 Jul 2003 05:18:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64CIPZ2085750 for ietf-sasl-bks; Fri, 4 Jul 2003 05:18:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64CIOqt085745 for ; Fri, 4 Jul 2003 05:18:24 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (82-43-138-23.cable.ubr01.newm.blueyonder.co.uk [82.43.138.23]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h64CM1V13552; Fri, 4 Jul 2003 06:22:01 -0600 Message-ID: <3F057089.DE9855FB@isode.com> Date: Fri, 04 Jul 2003 06:18:17 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Siemborski CC: Greg Hudson , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: > On Thu, 3 Jul 2003, Alexey Melnikov wrote: > > > Ok people. I am afraid we are starting a religious war at this point and > > this is not going to do us any good. > > I agree. > > > So, how about making some constructive suggestions. How about the following: > > 1). libraries MUST NOT specify callbacks when calling > > sasl_client_init/sasl_server_init. > > Global callbacks are thus deprecated. > > > > 2). a new function is added to set getopt callback. An application that > > doesn't care about getopt, will not call this function. If this callback > > is not set, the SASL library will use reasonable defaults or get the > > required information from own config file/environment/registry/whatever. > > > > 3). one of the getopt options is a plugin directory. If the application doesn't > > care, its getopt callback will fail to return the value for this option. The > > SASL library will choose a reasonable default in this case. If the SASL library > > doesn't support plugins, it will not care about this option. > > This is worse than the global callbacks scenario with libraries forbidden > from setting global callbaks, since in this situation a libary can call > the magic new function to set the getopt() callback. IMHO, it is not different. You can't prevent libraries or applications from doing stupid things, you can only advise them how to avoid problems. > I don't see how this is better than allowing a getopt() callback to be set > by the application, but not by libraries in the call to sasl_xxx_init(). Would you rather allow getopt (and only getopt) to be set by the application when calling a sasl_xxx_init() and a library using SASL always pass NULL as callbacks? > Even if we forbid libraries from calling this new function, the situation > is worse than allowing applications to set a getopt callback in their call > to sasl_xxx_init(), as it requires changes from current practice. > > > I believe this is how it works now anyway (except for new function for setting > > getopt). > > Not quite true, this requires standardizing the name of an option, as > well. I meant in Cyrus SASL library, not the document. Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Fri Jul 4 05:39:03 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64Cd3qt086288 for ; Fri, 4 Jul 2003 05:39:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64Cd3j0086287 for ietf-sasl-bks; Fri, 4 Jul 2003 05:39:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64Cd2qt086282 for ; Fri, 4 Jul 2003 05:39:02 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (82-43-138-23.cable.ubr01.newm.blueyonder.co.uk [82.43.138.23]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h64CgfV13699; Fri, 4 Jul 2003 06:42:42 -0600 Message-ID: <3F057561.23539745@isode.com> Date: Fri, 04 Jul 2003 06:38:57 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg Hudson CC: ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> <1057272175.12524.444.camel@error-messages.mit.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greg Hudson wrote: > On Thu, 2003-07-03 at 18:27, Alexey Melnikov wrote: > > So, how about making some constructive suggestions. How about the following: > > 1). libraries MUST NOT specify callbacks when calling > > sasl_client_init/sasl_server_init. > > Global callbacks are thus deprecated. > > You seem to leave open the question of whether applications are allowed > to specify callbacks. Sorry, forgot about that. Either an application should pass NULL as a library (and new function is introduced for setting getopt as described), or the application is only allowed to set getopt as a global callback. In this case interaction between global callbacks and local one should be documented. > Was that intentional? No. > (As I've mentioned before, if applications are allowed to set global > callbacks, then a library using SASL cannot guard against accidentally > triggering the application global callbacks.) > > > 2). a new function is added to set getopt callback. An application that doesn't > > care about getopt, will not call this function. > > Well, as everybody knows, my religion does not include such a device, > but global state is generally not burdensome as long as it's > (completely) optional. So I won't scream and yell about it. I was hoping for this :-). Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Fri Jul 4 07:32:36 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64EWaqt090184 for ; Fri, 4 Jul 2003 07:32:36 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64EWatw090183 for ietf-sasl-bks; Fri, 4 Jul 2003 07:32:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64EWZqt090176 for ; Fri, 4 Jul 2003 07:32:35 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (82-43-138-23.cable.ubr01.newm.blueyonder.co.uk [82.43.138.23]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h64EaFV14473; Fri, 4 Jul 2003 08:36:15 -0600 Message-ID: <3F058FFF.E7D32D15@isode.com> Date: Fri, 04 Jul 2003 08:32:31 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Siemborski CC: Greg Hudson , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> <3F057089.DE9855FB@isode.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: > On Fri, 4 Jul 2003, Alexey Melnikov wrote: > > > > I don't see how this is better than allowing a getopt() callback to be set > > > by the application, but not by libraries in the call to sasl_xxx_init(). > > > > Would you rather allow getopt (and only getopt) to be set by the > > application when calling a sasl_xxx_init() and a library using SASL > > always pass NULL as callbacks? > > Yes, since it is much closer to what is currently done, and I don't see > the gain of adding a separate "set getopt" function which needs to be > called before sasl_xxx_init anyway. If there's a concrete gain that > justified the change in code, I'd be less opposed. > > > > Not quite true, this requires standardizing the name of an option, as > > > well. > > > > I meant in Cyrus SASL library, not the document. > > So option names would still be non-standard? Doesn't this not address > Greg's concern then? I think it should be standard, but Greg wouldn't care :-). Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Fri Jul 4 07:29:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64ETbqt089725 for ; Fri, 4 Jul 2003 07:29:37 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64ETb4t089724 for ietf-sasl-bks; Fri, 4 Jul 2003 07:29:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64ETVqt089704 for ; Fri, 4 Jul 2003 07:29:31 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h64ETVuO013505; Fri, 4 Jul 2003 10:29:31 -0400 Date: Fri, 4 Jul 2003 10:29:31 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: Greg Hudson , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library In-Reply-To: <3F057089.DE9855FB@isode.com> Message-ID: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> <3F057089.DE9855FB@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 4 Jul 2003, Alexey Melnikov wrote: > > I don't see how this is better than allowing a getopt() callback to be set > > by the application, but not by libraries in the call to sasl_xxx_init(). > > Would you rather allow getopt (and only getopt) to be set by the > application when calling a sasl_xxx_init() and a library using SASL > always pass NULL as callbacks? Yes, since it is much closer to what is currently done, and I don't see the gain of adding a separate "set getopt" function which needs to be called before sasl_xxx_init anyway. If there's a concrete gain that justified the change in code, I'd be less opposed. > > Not quite true, this requires standardizing the name of an option, as > > well. > > I meant in Cyrus SASL library, not the document. So option names would still be non-standard? Doesn't this not address Greg's concern then? -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 Fri Jul 4 07:46:16 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64EkGqt091563 for ; Fri, 4 Jul 2003 07:46:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64EkGCo091562 for ietf-sasl-bks; Fri, 4 Jul 2003 07:46:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64EkEqt091557 for ; Fri, 4 Jul 2003 07:46:15 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h64EkFIi009942; Fri, 4 Jul 2003 10:46:15 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h64Ek52e010251; Fri, 4 Jul 2003 10:46:05 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h64Ek4FJ027290; Fri, 4 Jul 2003 10:46:04 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h64Ek3Ai026695; Fri, 4 Jul 2003 10:46:03 -0400 Subject: Re: Using SASL C API from a library From: Greg Hudson To: Alexey Melnikov Cc: ietf-sasl@imc.org In-Reply-To: <3F057561.23539745@isode.com> References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> <1057272175.12524.444.camel@error-messages.mit.edu> <3F057561.23539745@isode.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057329958.12524.476.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 04 Jul 2003 10:46:03 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 2003-07-04 at 08:38, Alexey Melnikov wrote: > Sorry, forgot about that. Either an application should pass NULL as a library (and > new function is introduced for setting getopt as described), or the application is > only allowed to set getopt as a global callback. In this case interaction between > global callbacks and local one should be documented. It sounds like we get the simplest transition if we make the changes: * Libraries must pass NULL for the global callbacks. * Applications must pass NULL, or only a getopt callback. * Applications MAY pass a getopt callback, but we don't say they SHOULD. Existing SASL implementations don't have to do anything except modify their documentation. To resolve my other issue while still preserving the ability to use a non-standard thread library: * sasl_set_mutex() becomes optional, but must be called from the initial single-threaded environment if it is called at all. If it is not called, the library will use the most standard native thread APIs to protect any internal global state. * sasl_*_init() no longer needs to be called from the initial single-threaded environment. This change is more burdensome.for existing implementations which have internal global state to protect; they must use threads (I'm told the pthreads API works under Windows, but I don't know how advisable it is to use it) and introduce a link-time dependency on a threads library. But the API does then become safely usable from a library. (I am okay with allowing implementations to simply not advertise thread safety, in which case they don't need to implement their own locks.) These changes do not turn the API into a shining example of standard API design in my book, of course; they are merely proposed as a practical compromise. Rob Siemborski wrote: > So option names would still be non-standard? Doesn't this not address > Greg's concern then? There are my concerns about the API's practical usability from a library, and there are my concerns about good design of a standard API, and I haven't kept them separate in this discussion. The former concerns are mostly objective, but it's clear that the other members of this working group don't agree with me on the latter concerns, so I will try to stick to the former. With that proviso, having a pseudo-standardized getopt() is okay as long as we don't enforce its use by callers. So I have concerns with the following text in the current draft: The most important callback is the "getopt" callback (see section 3.3.3) which is used to retrieve security policy option set- tings from the caller's preferences. This text worries me because the getopt callback is referred to as "important" and because security policy should be retrieved through a fully standard interface. (That may require a lot of work; I haven't thought about that problem in great detail.) Imagine trying to build an application which has a GUI to configure security policy preferences using the current design. The callbacks argument is the default list of callbacks (see sec- tion 3.1.1 for definition of sasl_callback_t structure) and SHOULD include the sasl_getopt_t callback (see section 3.3.3). This text worries me because, again, it seems to expect that the implementation will really want to see a getopt callback and will behave only minimally usefully without one. From owner-ietf-sasl Fri Jul 4 08:16:03 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64FG2qt093945 for ; Fri, 4 Jul 2003 08:16:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64FG2IG093944 for ietf-sasl-bks; Fri, 4 Jul 2003 08:16:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64FG1qt093939 for ; Fri, 4 Jul 2003 08:16:01 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h64FG1uO014471; Fri, 4 Jul 2003 11:16:01 -0400 Date: Fri, 4 Jul 2003 11:16:00 -0400 (EDT) From: Rob Siemborski To: Greg Hudson cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library In-Reply-To: <1057329958.12524.476.camel@error-messages.mit.edu> Message-ID: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> <1057272175.12524.444.camel@error-messages.mit.edu> <3F057561.23539745@isode.com> <1057329958.12524.476.camel@error-messages.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 Fri, 4 Jul 2003, Greg Hudson wrote: > On Fri, 2003-07-04 at 08:38, Alexey Melnikov wrote: > > Sorry, forgot about that. Either an application should pass NULL as a library (and > > new function is introduced for setting getopt as described), or the application is > > only allowed to set getopt as a global callback. In this case interaction between > > global callbacks and local one should be documented. > > It sounds like we get the simplest transition if we make the changes: > > * Libraries must pass NULL for the global callbacks. > * Applications must pass NULL, or only a getopt callback. > * Applications MAY pass a getopt callback, but we don't say they > SHOULD. > > Existing SASL implementations don't have to do anything except modify > their documentation. I'm okay with this. > To resolve my other issue while still preserving the ability to use a > non-standard thread library: > > * sasl_set_mutex() becomes optional, but must be called from the > initial single-threaded environment if it is called at all. If > it is not called, the library will use the most standard native > thread APIs to protect any internal global state. > * sasl_*_init() no longer needs to be called from the initial > single-threaded environment. > > This change is more burdensome.for existing implementations which have > internal global state to protect; they must use threads (I'm told the > pthreads API works under Windows, but I don't know how advisable it is > to use it) and introduce a link-time dependency on a threads library. > But the API does then become safely usable from a library. > > (I am okay with allowing implementations to simply not advertise thread > safety, in which case they don't need to implement their own locks.) If this change allows for implementations to advertise thread safety only if sasl_set_mutex is called (from a non-threaded environment), I'm at least willing to talk about this. First, I think that calling sasl_set_mutex needs to be a "SHOULD" and not "OPTIONAL". I also worry a bit about sasl_xxx_init not being required to be called from a single non-threaded environment, since in order to simulate this the library would need to lock around it. If sasl_set_mutex has been called, presumably this means that sasl_set_mutex allocates the necessary mutex, but now we can never release this mutex safely (well, unless sasl_set_mutex was called again with all NULL values, I suppose). This may not be a practical concern. > These changes do not turn the API into a shining example of standard API > design in my book, of course; they are merely proposed as a practical > compromise. As you can probably understand, its really hard for me to not oppose significant changes in the API as we try to standardize it. We've already implemented two substantially different SASL APIs, I'm not looking forward to doing it a third time, especially given the deployment we currently have. Making it usable is one thing (for which I am willing to compromise), however making it a "shining example of API design" in ways that are not backwards compatible, just for the sake of doing so is probably going to see pushback. > The most important callback is the "getopt" callback (see > section 3.3.3) which is used to retrieve security policy option set- > tings from the caller's preferences. > > This text worries me because the getopt callback is referred to as > "important" and because security policy should be retrieved through a > fully standard interface. (That may require a lot of work; I haven't > thought about that problem in great detail.) Imagine trying to build an > application which has a GUI to configure security policy preferences > using the current design. I tend to agree that "security policy" decisions should be done through standard interfaces. Of course, if things like telling the mechanisms what database to pull user secrets from (or how to authenticate to that database, or so on) is a "security policy" decision, we're going to have problems defining any standard interface to deal with this. I think this sentence can just be eliminated, it doesn't really add anything useful to section 3.3.1. > The callbacks argument is the default list of callbacks (see sec- > tion 3.1.1 for definition of sasl_callback_t structure) and SHOULD > include the sasl_getopt_t callback (see section 3.3.3). > > This text worries me because, again, it seems to expect that the > implementation will really want to see a getopt callback and will behave > only minimally usefully without one. I'm willing to change SHOULD to a MAY here (for applications), and MUST NOT (for libraries). Something like: The callbacks argument is the default list of callbacks (see section 3.1.1 for definition of sasl_callback_t structure). Libraries that are clients of the API MUST supply NULL For this parameter. Applications that are clients of the API MAY supply a list that includes the sasl_getopt_t callback, but MUST NOT supply any other callbacks through this interface. -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 Fri Jul 4 08:27:31 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64FRVqt094204 for ; Fri, 4 Jul 2003 08:27:31 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64FRVG4094203 for ietf-sasl-bks; Fri, 4 Jul 2003 08:27:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64FRUqt094198 for ; Fri, 4 Jul 2003 08:27:30 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h64FRUIi016142; Fri, 4 Jul 2003 11:27:30 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h64FRPcd011263; Fri, 4 Jul 2003 11:27:30 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h64FRNU8009085; Fri, 4 Jul 2003 11:27:24 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h64FRK9e026733; Fri, 4 Jul 2003 11:27:20 -0400 Subject: Re: Using SASL C API from a library From: Greg Hudson To: Rob Siemborski Cc: ietf-sasl@imc.org In-Reply-To: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> <1057272175.12524.444.camel@error-messages.mit.edu> <3F057561.23539745@isode.com> <1057329958.12524.476.camel@error-messages.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057332439.12524.484.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 04 Jul 2003 11:27:20 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I understand not wanting to make incompatible changes to the API at this time. On Fri, 2003-07-04 at 11:16, Rob Siemborski wrote: > If this change allows for implementations to advertise thread safety only > if sasl_set_mutex is called (from a non-threaded environment), I'm at least > willing to talk about this. Well, as long as they're clear, they can hedge all they want, I suppose. > I also worry a bit about sasl_xxx_init not being required to be called > from a single non-threaded environment, since in order to simulate this > the library would need to lock around it. If sasl_set_mutex has been > called, presumably this means that sasl_set_mutex allocates the necessary > mutex, but now we can never release this mutex safely (well, unless > sasl_set_mutex was called again with all NULL values, I suppose). This > may not be a practical concern. pthreads allows you to create a statically intialized mutex. You'd never release such a beast; you'd just use it to lock around non-thread-safe operations. > The callbacks argument is the default list of callbacks (see section 3.1.1 > for definition of sasl_callback_t structure). Libraries that are clients > of the API MUST supply NULL For this parameter. Applications that are > clients of the API MAY supply a list that includes the sasl_getopt_t > callback, but MUST NOT supply any other callbacks through this interface. That looks okay to me. From owner-ietf-sasl Fri Jul 4 08:37:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64Fbnqt095264 for ; Fri, 4 Jul 2003 08:37:49 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64Fbn3a095263 for ietf-sasl-bks; Fri, 4 Jul 2003 08:37:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64Fblqt095256 for ; Fri, 4 Jul 2003 08:37:47 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp6.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h64Fblil005193; Fri, 4 Jul 2003 11:37:47 -0400 Date: Fri, 4 Jul 2003 11:37:47 -0400 (EDT) From: Rob Siemborski To: Greg Hudson cc: ietf-sasl@imc.org Subject: Re: Using SASL C API from a library In-Reply-To: <1057332439.12524.484.camel@error-messages.mit.edu> Message-ID: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> <1057272175.12524.444.camel@error-messages.mit.edu> <3F057561.23539745@isode.com> <1057329958.12524.476.camel@error-messages.mit.edu> <1057332439.12524.484.camel@error-messages.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 Fri, 4 Jul 2003, Greg Hudson wrote: > > I also worry a bit about sasl_xxx_init not being required to be called > > from a single non-threaded environment, since in order to simulate this > > the library would need to lock around it. If sasl_set_mutex has been > > called, presumably this means that sasl_set_mutex allocates the necessary > > mutex, but now we can never release this mutex safely (well, unless > > sasl_set_mutex was called again with all NULL values, I suppose). This > > may not be a practical concern. > > pthreads allows you to create a statically intialized mutex. You'd > never release such a beast; you'd just use it to lock around > non-thread-safe operations. That's true. However, if sasl_set_mutex *is* called we have no way of staticly allocating a mutex, since we have to dynamicly call the init function to get the proper mutex (and we may not be using pthread mutexes). -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 Fri Jul 4 08:47:00 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64Fl0qt096345 for ; Fri, 4 Jul 2003 08:47:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64Fl0r0096344 for ietf-sasl-bks; Fri, 4 Jul 2003 08:47:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64Fkxqt096337 for ; Fri, 4 Jul 2003 08:46:59 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h64Fkwc6086291; Fri, 4 Jul 2003 15:46:58 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030704084120.01c76430@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 04 Jul 2003 08:43:53 -0700 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-anon-02.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200307022034.QAA13327@ietf.org> <200307022034.QAA13327@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 11:35 AM 7/3/2003, Rob Siemborski wrote: >On Wed, 2 Jul 2003 Internet-Drafts@ietf.org wrote: > > >> Title : The Anonymous SASL Mechanism >> Author(s) : K. Zeilenga >> Filename : draft-ietf-sasl-anon-02.txt > >>> >...not part of SASL itself. Newer profiles of SASL will include the >client message with the AUTHENTICATE command itself so the extra round >trip below (the server response with an empty "+ ") can be eliminated. ><< > >Seems to indicate a requirement on new SASL profiles, which is outside of >the scope of the document. However, it is reasonable to add some >clarification that the extra round trip is an artifact of the IMAP >profile. > >How about something more like: > >...not part of SASL itself. Additionally, protocols with SASL profiles >permitting an initial client response will be able to avoid the extra >round trip below (the server response with an empty "+ "). This sounds like a reasonable suggestion... Kurt From owner-ietf-sasl Sat Jul 5 21:52:47 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h664qWqt013065 for ; Sat, 5 Jul 2003 21:52:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h664qWAX013064 for ietf-sasl-bks; Sat, 5 Jul 2003 21:52:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-TWO-SIXTY-TWO.MIT.EDU [18.187.6.7]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h664pAqt013041 for ; Sat, 5 Jul 2003 21:51:10 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 7A798151D96; Sun, 6 Jul 2003 00:51:02 -0400 (EDT) To: Alexey Melnikov Cc: Greg Hudson , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> From: Sam Hartman Date: Sun, 06 Jul 2003 00:51:02 -0400 In-Reply-To: <3F04ADD2.31E16D8B@isode.com> (Alexey Melnikov's message of "Thu, 03 Jul 2003 16:27:30 -0600") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> Ok people. I am afraid we are starting a religious war at Alexey> this point and this is not going to do us any good. If this were a WG item I'd disagree that anyone was proposing a religious war. I'd comment that there seems to be an unspecified requirement behind the global getopt callback. I'd ask the proponents of that callback to describe clearly what problem it was trying to solve. Then, I'd see if the WG could reach consensus on whether that problem was a good thing to solve in a standards track API. If the WG reached consensus on a problem and agreed the problem was worth solving, then we would look at whether the getopt callback actually solved that problem. But this document is not a WG item; you can use whatever procedure you like to decide its contents. From owner-ietf-sasl Mon Jul 7 10:23:33 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67HNXqt079048 for ; Mon, 7 Jul 2003 10:23:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h67HNX3s079047 for ietf-sasl-bks; Mon, 7 Jul 2003 10:23:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (HOTASS-3.MIT.EDU [18.101.1.43]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67HNWqt079042 for ; Mon, 7 Jul 2003 10:23:32 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 6443915201D; Mon, 7 Jul 2003 13:23:33 -0400 (EDT) To: ietf-sasl@imc.org Subject: Proposed Agenda From: Sam Hartman Date: Mon, 07 Jul 2003 13:23:33 -0400 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: People should speak up today if there are other issues that need to be covered. 1) preliminary stuff - 5m 2) 2222bis - 15m 3) saslprep - 15m 4) other issues - 15m 5) open mic - remainder From owner-ietf-sasl Thu Jul 10 14:55:05 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6ALt5qt019518 for ; Thu, 10 Jul 2003 14:55:05 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6ALt5KP019517 for ietf-sasl-bks; Thu, 10 Jul 2003 14:55:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6ALswqt019503 for ; Thu, 10 Jul 2003 14:55:04 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust29.tnt101.lnd4.gbr.da.uu.net [213.116.50.29]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h6ALwSV18970; Thu, 10 Jul 2003 15:58:30 -0600 Message-ID: <3F0DD586.77AD0B39@isode.com> Date: Thu, 10 Jul 2003 15:07:18 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Proposed Agenda References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: > People should speak up today if there are other issues that need to be covered. > > 1) preliminary stuff - 5m > 2) 2222bis - 15m > 3) saslprep - 15m > 4) other issues - 15m > 5) open mic - remainder There is a 50% chance that I will not be in Vienna (and there is some probability that even if I will be, I might miss the SASL meeting). Any takers to serve as proxy for me (i.e. 2222bis document and DIGEST-MD5)? Can we also have a virtual "show of hands" for people who are planning to attend? Please send replies to me and I will post the list to the mailing list. I am not sure what is included in "other issues", but some potential topics for discussion: 1). SASL C API (out of scope, but a lot of discussion lately) 2). Status of GSSAPI draft now that the base32 document is an RFC? Also, I've asked Application Area ADs for a slot to talk about HTTP SASL during Application Area Open Meeting on Monday. Assuming there is time, Peter Yee from RSA will present if I am not present. Cheers, Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Fri Jul 11 19:24:35 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6C2OZqt035790 for ; Fri, 11 Jul 2003 19:24:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6C2OZm8035789 for ietf-sasl-bks; Fri, 11 Jul 2003 19:24:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smith.dodgethis.org (postfix@netblock-66-159-211-115.dslextreme.com [66.159.211.115]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6C2OXqt035784 for ; Fri, 11 Jul 2003 19:24:33 -0700 (PDT) (envelope-from wpc4@dodgethis.org) Received: from dejour (dejour.dodgethis.org [192.168.0.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smith.dodgethis.org (Postfix) with ESMTP id 22ABA37ACC for ; Fri, 11 Jul 2003 19:24:34 -0700 (PDT) Message-ID: <000a01c3481c$c96eecc0$0600a8c0@dejour> From: "William Curley" To: Subject: SASL w/auxprop(mysql) and shadow {Scanned} Date: Fri, 11 Jul 2003 19:24:56 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C347E2.1C5D6690" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C347E2.1C5D6690 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am trying to allow Postfix to authenticate via SASL to send email, = SASL will either use the local shadow file or a mysql database to do the = authentication. I currently have this setup more or less using = 'saslauthd -a pam' and mysql-pam. I'd really like to just use SASL since = it appears to support this. I understand that auxprop can connect to a = mysql database, how do I start auxprop so it can do this? Or do I need = to do this? With both pwcheck and saslauthd I've had to have the daemons = running for it to work. Lastly, is it even possible to have SASL try to = authenticate to both shadow and mysql at the same time? Thanks kindly = for any light you can shed on this. William Curley wpc4@dodgethis.org http://www.dodgethis.org - Free email and more. ------=_NextPart_000_0007_01C347E2.1C5D6690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am trying to allow Postfix to = authenticate via=20 SASL to send email, SASL will either use the local shadow file or a = mysql=20 database to do the authentication. I currently have this setup more or = less=20 using 'saslauthd -a pam' and mysql-pam. I'd really like to just use SASL = since=20 it appears to support this. I understand that auxprop can connect to a = mysql=20 database, how do I start auxprop so it can do this? Or do I need to do = this?=20 With both pwcheck and saslauthd I've had to have the daemons running for = it to=20 work. Lastly, is it even possible to have SASL try to authenticate to = both=20 shadow and mysql at the same time? Thanks kindly for any light you can = shed on=20 this.
 
 
William Curley
wpc4@dodgethis.org
http://www.dodgethis.org - Free = email and=20 more.
------=_NextPart_000_0007_01C347E2.1C5D6690-- From owner-ietf-sasl Sat Jul 12 03:35:36 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6CAZaqt076201 for ; Sat, 12 Jul 2003 03:35:36 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6CAZa48076200 for ietf-sasl-bks; Sat, 12 Jul 2003 03:35:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6CAZVqt076194 for ; Sat, 12 Jul 2003 03:35:35 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust97.tnt102.lnd4.gbr.da.uu.net [213.116.52.97]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h6CAdAV03350; Sat, 12 Jul 2003 04:39:10 -0600 Message-ID: <3F0F3D08.F71EEEEF@isode.com> Date: Fri, 11 Jul 2003 16:41:12 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: Proposed Agenda References: <3F0DD586.77AD0B39@isode.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Can we also have a virtual "show of hands" for people who are planning to attend? > Please send replies to me and I will post the list to the mailing list. So far I've received only two replies from Sam Hartman and Keith Burdis. Kurt Zeilenga should be also in Vienna. Alexey From owner-ietf-sasl Mon Jul 14 00:06:56 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6E76uqt034338 for ; Mon, 14 Jul 2003 00:06:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6E76ssb034332 for ietf-sasl-bks; Mon, 14 Jul 2003 00:06:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6E76oqt034320 for ; Mon, 14 Jul 2003 00:06:53 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h6E76hc6080394; Mon, 14 Jul 2003 07:06:44 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030714035247.01cda048@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 14 Jul 2003 03:56:41 +0200 To: "William Curley" From: "Kurt D. Zeilenga" Subject: Re: SASL w/auxprop(mysql) and shadow {Scanned} Cc: In-Reply-To: <000a01c3481c$c96eecc0$0600a8c0@dejour> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As this list is for discussion regarding current and future SASL standardization efforts and, in particular, the work of the IETF SASL working group, your post is off topic. I suggest you direct your post to a list concerning CMU's Cyrus SASL implementation, e.g., . Kurt, IETF SASL WG co-chair At 04:24 AM 7/12/2003, William Curley wrote: >I am trying to allow Postfix to authenticate via SASL to send email, SASL will either use the local shadow file or a mysql database to do the authentication. I currently have this setup more or less using 'saslauthd -a pam' and mysql-pam. I'd really like to just use SASL since it appears to support this. I understand that auxprop can connect to a mysql database, how do I start auxprop so it can do this? Or do I need to do this? With both pwcheck and saslauthd I've had to have the daemons running for it to work. Lastly, is it even possible to have SASL try to authenticate to both shadow and mysql at the same time? Thanks kindly for any light you can shed on this. > > >William Curley >wpc4@dodgethis.org >http://www.dodgethis.org - Free email and more. From owner-ietf-sasl Tue Jul 15 08:25:21 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FFPLqt084338 for ; Tue, 15 Jul 2003 08:25:21 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6FFPLtb084337 for ietf-sasl-bks; Tue, 15 Jul 2003 08:25:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FFPKqt084331 for ; Tue, 15 Jul 2003 08:25:20 -0700 (PDT) (envelope-from jeffrey.t.moore@sun.com) Received: from jurassic.eng.sun.com ([129.146.17.55]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6FFPLRi004171 for ; Tue, 15 Jul 2003 09:25:21 -0600 (MDT) Received: from sun.com (vpn-129-150-19-113.SFBay.Sun.COM [129.150.19.113]) by jurassic.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h6FFPKte268007 for ; Tue, 15 Jul 2003 08:25:20 -0700 (PDT) Message-ID: <3F141CD8.AC475D3C@sun.com> Date: Tue, 15 Jul 2003 08:25:12 -0700 From: Jeff Moore X-Mailer: Mozilla 4.79 (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "ietf-sasl@imc.org" Subject: Global state and libsasl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As has been previously discussed, libsasl maintains global state which can cause problems when both an application and one of its libraries use libsasl. The most recent suggestions on how to deal with this issue in a compatible way do not seem to address all the issues with global state in the Cyrus libsasl implementation. The Cyrus 2.x libsasl implementation uses global state for the following: 1. Loading plugins If an application decides which plugins to load and how to configure them, any other consumers of libsasl may not not have their needs met. Additionally, some plugins may be specific to a given application or library. They may not want the plugin to be used by other components. There are a number of ways there could be problems: a. Location of plugins (SASL_CB_GETPATH) Through the SASL_CB_GETPATH callback. If this callback is specified, libsasl will use the specified path to locate plugins. The specified path may not include the standard plugins - or it may include "private" plugins. b. Verification of plugins/configuration (SASL_CB_VERIFYFILE) Through the SASL_CB_VERIFYFILE callback. What one component may accept another might reject. c. logging of non-connection oriented problems (SASL_CB_LOG) libraries will not be able to report these sorts of problems themselves. d. Setting any global plugin configuration data: e.g. DIGEST-MD5 - reauth_timeout, GSSAPI - keytab KERBEROS_4 - srvtab SRP - srp_mda The way to set these today is via the getopt function registered in the global callback. Also note that for things like reauth_timeout, you may not want to share it between different components. e. Loading application/library specific plugins Any plugin that is loaded via sasl_xxx_add_plugin will be available to application or libraries. f. Loading application/library private plugins 2. memory allocation sasl_set_alloc() setting memory allocation functions may have unintended interactions between application and libraries. If the library has already used libsasl to perform some memory allocations before the application has set sasl_set_alloc(), bad things may happen. 3. mutex functions sasl_set_mutex() setting mutex allocation functions may have unintended interactions between applications and libraries. If this function is a MUST, what should a library do? 4. sasl_xxx_init() and sasl_done() Count of usage may deal with this - although no separation between client and server and potential for misbehaving applications/libraries to break others. 5. Global callbacks If specified, they will apply to both application and libraries. The application's global callbacks may end up handling callbacks for the library. If, as has been proposed, that libraries should not use global callbacks, the application will not see this problem. 6. Server sasl option configuration file Just as with global callbacks, options may be set for library that are not expected or wanted. 7. Requirement of non-thread-safe initialization. Ideally, we would all like to see the global state problem be solved with a minimum of changes to the existing semantics. One way to address much of the above is to introduce a sasl global context that would be inferred by the current sasl API, but which would allow libraries (or applications) to use libsasl independently of each other. (There are additional issues for sasl_set_alloc() and sasl_set_mutex().) This approach would introduce a number of new functions: void *sasl_create_context(void) Create a sasl global context - the current global state would be now associated with the created context. void sasl_free_context(void *ctx) Release all resources associated with the sasl global context. This would be semantically the same as the current sasl_done(). int _sasl_client_init(void *ctx, const sasl_callback_t *callbacks); Initialize the sasl global context for sasl client access. int _sasl_client_new(void *ctx, const char *service, ...) Create a sasl client connection using the sasl global context. int _sasl_server_init(void *ctx, const sasl_callback_t *callbacks, ...); Initialize the sasl global context for sasl server access. int _sasl_server_new(void *ctx, const char *service, ...) Create a sasl server connection using the sasl global context. int _sasl_client_add_plugin(void *ctx, const char *plugname, ...); int _sasl_server_add_plugin(void *ctx, const char *plugname, ...); int _sasl_canonuser_add_plugin(void *ctx, const char *plugname, ...); int _sasl_auxprop_add_plugin(void *ctx, const char *plugname, ...); Add plugins to the sasl global context The functions sasl_set_mutex() and sasl_global_listmech() would be deprecated. If sasl_set_alloc() is not deprecated, then _sasl_set_alloc(void *ctx, ...) could be defined. This approach would preserve the existing semantic and avoid: global state issues when a library initializes the libsasl before the application, the potential problem of applications getting callbacks for libraries and plugins installed by one component being available for use by other components. Cheers, Jeff From owner-ietf-sasl Tue Jul 15 09:22:02 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FGM2qt086896 for ; Tue, 15 Jul 2003 09:22:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6FGM2Re086895 for ietf-sasl-bks; Tue, 15 Jul 2003 09:22:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FGM1qt086890 for ; Tue, 15 Jul 2003 09:22:01 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h6FGM2g4018998; Tue, 15 Jul 2003 12:22:02 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h6FGM2jH007752; Tue, 15 Jul 2003 12:22:02 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h6FGM1U8009513; Tue, 15 Jul 2003 12:22:01 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h6FGM0YH015609; Tue, 15 Jul 2003 12:22:00 -0400 Subject: Re: Global state and libsasl From: Greg Hudson To: Jeff Moore Cc: "ietf-sasl@imc.org" In-Reply-To: <3F141CD8.AC475D3C@sun.com> References: <3F141CD8.AC475D3C@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1058286116.13068.69.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 15 Jul 2003 12:22:00 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2003-07-15 at 11:25, Jeff Moore wrote: > int _sasl_client_init(void *ctx, const sasl_callback_t *callbacks); What's with the leading underscores? Symbols like that are reserved for external linkage by the ANSI C standard. From owner-ietf-sasl Wed Jul 16 01:06:33 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6G86Xqt046115 for ; Wed, 16 Jul 2003 01:06:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6G86XDF046114 for ietf-sasl-bks; Wed, 16 Jul 2003 01:06:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu ([81.160.157.184]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6G86Wqt046108 for ; Wed, 16 Jul 2003 01:06:32 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id ED6AD151D60; Wed, 16 Jul 2003 04:06:23 -0400 (EDT) To: housley@vigilsec.com, smb@research.att.com Cc: ietf-sasl@imc.org Subject: Summary of the SASL working group meeting From: Sam Hartman Date: Wed, 16 Jul 2003 04:06:23 -0400 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: The SASL working group met on Tuesday for one hour. The document editor of RFC 2222bis (Alexei) will publish a revision in the first week of August at which point we will last call it. The saslprep document is to be revised to include informational mapping tables but is otherwise ready for last call. New revision is expected shortly after the meeting and the last call will follow shortly after it is announced. Working group participants who made comments during the plain or anonymous last call need to make sure their comments are reflected in the current document. The document editor believes that the working group is done with these two documents although we are not sending them to the IESG at this time. The working group decided that AES for digest-md5 will use random IVs rather than counter mode. Counter mode is harder to implement correctly. There is likely to be interest in making the RC4 cipher mandatory-to-implement for implementations that support confidentiality with digest-md5. The RC4 cipher is interoperable with existing implementations and we did not find any problems during the security review conducted after the last meeting. Currently, neither integrity protection nor confidentiality is mandatory-to-implement. At least one participant said he would remove digest-md5 support rather than implement integrity. The argument is that you can just use TLS. However, if you just use TLS, you need to depend on TLS to authenticate the server to the client or you have a man-in-the-mdille problem. This will be discussed on the list. The working group reached a consensus at the meeting to deprecate DES and 3DES because they are insecure. Larry submitted a 00 version of the GSSAPI draft, but it did not appear. He will resubmit in the near future. Keith Burdis agreed to submit an SASL applicability statement as an individual submission. His document will include comparisons of the various sasl mechanisms and their security properties. Sam agreed to propose an outline for the document. The working group will discuss rechartering to include this document after the first revision. From owner-ietf-sasl Wed Jul 16 06:34:31 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GDYVqt082636 for ; Wed, 16 Jul 2003 06:34:31 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6GDYVsT082635 for ietf-sasl-bks; Wed, 16 Jul 2003 06:34:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GDYTqt082630 for ; Wed, 16 Jul 2003 06:34:29 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h6GDYPGv030702 for ; Wed, 16 Jul 2003 09:34:25 -0400 (EDT) Message-ID: <3F1554B6.9090601@oceana.com> Date: Wed, 16 Jul 2003 09:35:50 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: SASL mailing list Subject: Re: Summary of the SASL working group meeting References: In-Reply-To: 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: > Keith Burdis agreed to submit an SASL applicability statement as an > individual submission. His document will include comparisons of the > various sasl mechanisms and their security properties. Sam agreed to > propose an outline for the document. The working group will discuss > rechartering to include this document after the first revision. How will this document differ from the following? http://www.ietf.org/internet-drafts/draft-iab-auth-mech-00.txt -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Wed Jul 16 08:21:36 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GFLZqt086322 for ; Wed, 16 Jul 2003 08:21:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6GFLZVn086321 for ietf-sasl-bks; Wed, 16 Jul 2003 08:21:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu ([81.160.157.184]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GFLYqt086294 for ; Wed, 16 Jul 2003 08:21:34 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 21B06151D76; Wed, 16 Jul 2003 11:21:27 -0400 (EDT) To: Ken Murchison Cc: SASL mailing list Subject: Re: Summary of the SASL working group meeting References: <3F1554B6.9090601@oceana.com> From: Sam Hartman Date: Wed, 16 Jul 2003 11:21:27 -0400 In-Reply-To: <3F1554B6.9090601@oceana.com> (Ken Murchison's message of "Wed, 16 Jul 2003 09:35:50 -0400") 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: >>>>> "Ken" == Ken Murchison writes: Ken> Sam Hartman wrote: >> Keith Burdis agreed to submit an SASL applicability statement >> as an individual submission. His document will include >> comparisons of the various sasl mechanisms and their security >> properties. Sam agreed to propose an outline for the document. >> The working group will discuss rechartering to include this >> document after the first revision. Ken> How will this document differ from the following? Ken> http://www.ietf.org/internet-drafts/draft-iab-auth-mech-00.txt The IAB document seems to discuss mechanisms at a much lower level. I was invisioning comparing SASL to similar technologies like EAP, GSSAPI and TLS. And I was hoping to discuss sasl mechansims as sasl mechanisms. We should definitely point to the IAB document and when discussing mechanisms describe them in the category they fit into that framework. From owner-ietf-sasl Fri Jul 18 09:32:07 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IGW6qt007102 for ; Fri, 18 Jul 2003 09:32:06 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6IGW6Yr007101 for ietf-sasl-bks; Fri, 18 Jul 2003 09:32:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IGW2qt007092 for ; Fri, 18 Jul 2003 09:32:03 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h6IGVmGv003090; Fri, 18 Jul 2003 12:31:48 -0400 (EDT) Message-ID: <3F18214A.2030706@oceana.com> Date: Fri, 18 Jul 2003 12:33:14 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Keith Burdis , "Raif S. Naffah" CC: SASL mailing list Subject: draft-burdis-cat-srp-sasl-08 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: Trying to bring Cyrus SASL in to compliance with the latest draft. Here are some notes I put together after a thorough read of the auth exchange. I may have more when I get into integrity and security. Section 3.8: > When such entities travel on the wire, they shall be encoded as > 4-octet Scalar Numbers. We shall use the syntax uint(n) to denote > the encoding of an Unsigned Integer n. In what byte-order? I assume big-endian. Section 4.5: > The server computes its evidence M2, which proves to the client that > it knows the shared context key K, as well as U, I and o, as follows: ^^^ > > H( bytes(A) > | bytes(M1) > | bytes(K) Was U removed from the calculation on purpose, or was it an oversight? If its no longer part of the calculation, then it should be removed from the sentence describing M2. > | bytes(H( bytes(I) )) > | bytes(H( bytes(o) )) > | bytes(sid) If sid is UTF8, should it be hashed, like I and o? > | ttl Shouldn't this be bytes(ttl)? > ) > > All parameters received from the client that are used as input to a > digest operation MUST be used as received. > > The server sends: > > { os(M2) | os(sIV) | sid | ttl } ^^^^^^^^^^ Shouldn't this be utf8(sid) and uint(ttl)? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Tue Jul 22 14:54:44 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MLsiqt073585 for ; Tue, 22 Jul 2003 14:54:44 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6MLsiWd073584 for ietf-sasl-bks; Tue, 22 Jul 2003 14:54:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MLshqt073569 for ; Tue, 22 Jul 2003 14:54:43 -0700 (PDT) (envelope-from william.fiveash@sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6MLseDZ020776 for ; Tue, 22 Jul 2003 14:54:40 -0700 (PDT) Received: from alton.central.sun.com (alton.Central.Sun.COM [129.153.128.101]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6MLsdcm022888; Tue, 22 Jul 2003 15:54:39 -0600 (MDT) Received: from alton.central.sun.com (localhost [127.0.0.1]) by alton.central.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6MLsdkY463134; Tue, 22 Jul 2003 16:54:39 -0500 (CDT) Received: (from willf@localhost) by alton.central.sun.com (8.12.9+Sun/8.12.9/Submit) id h6MLsdXB463133; Tue, 22 Jul 2003 16:54:39 -0500 (CDT) X-Authentication-Warning: alton.central.sun.com: willf set sender to william.fiveash@sun.com using -f Date: Tue, 22 Jul 2003 16:54:39 -0500 From: Will Fiveash To: ietf-sasl@imc.org Cc: Jeff Moore Subject: Fwd: [Nicolas.Williams@sun.com: draft-ietf-cat-sasl-gssapi-XX.txt && error tokens] Message-ID: <20030722215438.GI456254@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Since Nico isn't subscribed I'm forwarding this for him. -- Will Fiveash Sun Microsystems Inc. Austin, TX, USA (TZ=CST6CDT) ----- Forwarded message from Nicolas Williams ----- Date: Tue, 22 Jul 2003 13:28:16 -0700 From: Nicolas Williams To: ietf-sasl@imc.org Subject: draft-ietf-cat-sasl-gssapi-XX.txt && error tokens User-Agent: Mutt/1.4i The last version of draft-ietf-cat-sasl-gssapi that I saw (-05) did not appropriately deal with GSS-API error tokens. Yes, there is such a thing as GSS-API error tokens, that is, GSS_Accept_sec_context() (and init too) can return a major status other than GSS_S_COMPLETE/GSS_S_CONTINUE_NEEDED *and* output a token at the same time. Such tokens SHOULD be sent. Sending GSS-API error tokens makes debugging errors a lot easier and results in error strings that make sense being displayed to the user. Also note: minor status codes are generally not standardized (certainly not for the Kerberos V GSS mechanism) and so minor error codes should not be sent on the wire as the peer may not be able to interpret them correctly (this is definitely the case with the Kerberos mech). Since I cannot find a current version of draft-ietf-cat-sasl-gssapi I will refrain from proposing actual text changes for now. Cheers, Nico -- ----- End forwarded message ----- From owner-ietf-sasl Tue Jul 22 16:25:32 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MNPJqt079502 for ; Tue, 22 Jul 2003 16:25:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6MNPJim079501 for ietf-sasl-bks; Tue, 22 Jul 2003 16:25:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MNO1qt079476 for ; Tue, 22 Jul 2003 16:24:01 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6MNNpxk014025; Tue, 22 Jul 2003 16:23:51 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6MNNocm023415; Tue, 22 Jul 2003 17:23:50 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h6MNKaQx010075; Tue, 22 Jul 2003 16:20:36 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6MNKZWk010074; Tue, 22 Jul 2003 18:20:35 -0500 (CDT) Date: Tue, 22 Jul 2003 18:20:35 -0500 From: Nicolas Williams To: ietf-sasl@imc.org, Keith Burdis , "Raif S. Naffah" Cc: Sam Hartman Subject: Comments on draft-burdis-cat-srp-sasl-08.txt Message-ID: <20030722232035.GD8918@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The following comments all pertain to the GSS-API mechanism defined in section 8 of draft-burdis-cat-srp-sasl-08.txt except where otherwise noted: 1. Mutual Authentication & SRP GSS Principal Naming The I-D claims to provide mutual authentication, but does not provide for naming acceptors. While I appreciate that SRP provides mutual authentication, unless one can bind the SRP password and verifier to an acceptor name then the acceptor name MUST be of type GSS_C_NT_ANONYMOUS. Sam Hartman has proposed appending, prepending or otherwise stirring the acceptor name into the password as a way to achieve mutual authentication with non-anonymous acceptors. The I-D should explain the limitations of its mutual authentication provision and/or add acceptor naming to the protocol. (See questions below.) Initiator naming should also be discussed. Additional questions: Should services be able to use this mechanism as initiators? How about optionally running the SRP protocol in both directions so that the initiator and acceptor can mutually authenticate without having to stir GSS-API names into the password/verifier? The two exchanges would have to be mutually bound, sure, perhaps in the last message of the double exchange. (In this case the verifiers could even be published, as long as they are distributed in a secure fashion.) 2. Channel Bindings I imagine that the I-D authors may have thought that GSS channel bindings are an esoteric, barely used feature of the GSS-API. A few months ago they have been correct. This is about to change; the use of GSS-API channel bindings is being formalized and given new life, see: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt If the protocol can be extended to accommodate integrity protected channel bindings I highly encourage you to do so. You can always define the encoding of the channel bindings by reference to RFC1964, module choice of hash function (this is how we're defining them for SPKM in draft-ietf-nfsv4-ccm-01.txt). 3. No Error Token Is Specified The GSS-API does, apparent widely spread assumptions notwithstanding, support the use of error tokens - i.e., output tokens emitted by gss_init_sec_context() or gss_accept_sec_context() when they also return a major status code other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED. This problem is significant. Please fix. 4. Obsoleted RFCs Do Not Make for Good Normative References This I-D references RFC2078 instead of RFC2743. Please fix. :) Cheers, Nico -- From owner-ietf-sasl Tue Jul 22 17:28:25 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6N0SOqt080945 for ; Tue, 22 Jul 2003 17:28:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6N0SOtg080944 for ietf-sasl-bks; Tue, 22 Jul 2003 17:28:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6N0SNqt080939 for ; Tue, 22 Jul 2003 17:28:23 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6N0SQEJ002193 for ; Tue, 22 Jul 2003 18:28:26 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6N0SPbO015631 for ; Tue, 22 Jul 2003 18:28:25 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h6N0PCQx010126 for ; Tue, 22 Jul 2003 17:25:12 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6N0PBJ9010125 for ietf-sasl@imc.org; Tue, 22 Jul 2003 19:25:11 -0500 (CDT) Date: Tue, 22 Jul 2003 18:20:35 -0500 From: Nicolas Williams To: ietf-sasl@imc.org, Keith Burdis , "Raif S. Naffah" Cc: Sam Hartman Subject: Comments on draft-burdis-cat-srp-sasl-08.txt Message-ID: <20030722232035.GD8918@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The following comments all pertain to the GSS-API mechanism defined in section 8 of draft-burdis-cat-srp-sasl-08.txt except where otherwise noted: 1. Mutual Authentication & SRP GSS Principal Naming The I-D claims to provide mutual authentication, but does not provide for naming acceptors. While I appreciate that SRP provides mutual authentication, unless one can bind the SRP password and verifier to an acceptor name then the acceptor name MUST be of type GSS_C_NT_ANONYMOUS. Sam Hartman has proposed appending, prepending or otherwise stirring the acceptor name into the password as a way to achieve mutual authentication with non-anonymous acceptors. The I-D should explain the limitations of its mutual authentication provision and/or add acceptor naming to the protocol. (See questions below.) Initiator naming should also be discussed. Additional questions: Should services be able to use this mechanism as initiators? How about optionally running the SRP protocol in both directions so that the initiator and acceptor can mutually authenticate without having to stir GSS-API names into the password/verifier? The two exchanges would have to be mutually bound, sure, perhaps in the last message of the double exchange. (In this case the verifiers could even be published, as long as they are distributed in a secure fashion.) 2. Channel Bindings I imagine that the I-D authors may have thought that GSS channel bindings are an esoteric, barely used feature of the GSS-API. A few months ago they have been correct. This is about to change; the use of GSS-API channel bindings is being formalized and given new life, see: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt If the protocol can be extended to accommodate integrity protected channel bindings I highly encourage you to do so. You can always define the encoding of the channel bindings by reference to RFC1964, module choice of hash function (this is how we're defining them for SPKM in draft-ietf-nfsv4-ccm-01.txt). 3. No Error Token Is Specified The GSS-API does, apparent widely spread assumptions notwithstanding, support the use of error tokens - i.e., output tokens emitted by gss_init_sec_context() or gss_accept_sec_context() when they also return a major status code other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED. This problem is significant. Please fix. 4. Obsoleted RFCs Do Not Make for Good Normative References This I-D references RFC2078 instead of RFC2743. Please fix. :) Cheers, Nico -- From owner-ietf-sasl Tue Jul 22 21:12:09 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6N4C9qt087807 for ; Tue, 22 Jul 2003 21:12:09 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6N4C9cT087806 for ietf-sasl-bks; Tue, 22 Jul 2003 21:12:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6N4C8qt087801 for ; Tue, 22 Jul 2003 21:12:08 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h6N4C8c6078307 for ; Wed, 23 Jul 2003 04:12:10 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030723060828.01b9cab8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 23 Jul 2003 06:08:52 +0200 To: ietf-sasl@imc.org From: Nicolas Williams Subject: draft-ietf-cat-sasl-gssapi-XX.txt && error tokens Mime-Version: 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 last version of draft-ietf-cat-sasl-gssapi that I saw (-05) did not appropriately deal with GSS-API error tokens. Yes, there is such a thing as GSS-API error tokens, that is, GSS_Accept_sec_context() (and init too) can return a major status other than GSS_S_COMPLETE/GSS_S_CONTINUE_NEEDED *and* output a token at the same time. Such tokens SHOULD be sent. Sending GSS-API error tokens makes debugging errors a lot easier and results in error strings that make sense being displayed to the user. Also note: minor status codes are generally not standardized (certainly not for the Kerberos V GSS mechanism) and so minor error codes should not be sent on the wire as the peer may not be able to interpret them correctly (this is definitely the case with the Kerberos mech). Since I cannot find a current version of draft-ietf-cat-sasl-gssapi I will refrain from proposing actual text changes for now. Cheers, Nico -- From owner-ietf-sasl Wed Jul 23 06:32:47 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NDWlqt041677 for ; Wed, 23 Jul 2003 06:32:47 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NDWlVa041676 for ietf-sasl-bks; Wed, 23 Jul 2003 06:32:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NDWjqt041663 for ; Wed, 23 Jul 2003 06:32:46 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id 76E2A76614; Wed, 23 Jul 2003 09:33:39 -0400 (EDT) To: Nicolas Williams Cc: ietf-sasl@imc.org, Keith Burdis , "Raif S. Naffah" Subject: Re: Comments on draft-burdis-cat-srp-sasl-08.txt References: <20030722232035.GD8918@binky.central.sun.com> From: Sam Hartman Date: Wed, 23 Jul 2003 09:33:39 -0400 In-Reply-To: <20030722232035.GD8918@binky.central.sun.com> (Nicolas Williams's message of "Tue, 22 Jul 2003 18:20:35 -0500") Message-ID: <87smox5pvw.fsf@luminous.mit.edu> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: To clarify, I don't believe that Nico's comments about mutual authentication actually are specific to the GSSAPI mechanism. The SRP SASL mechanism seems to only provide mutual authentication if the same password and verifier is used only on one server. I'm not sure how appropriate this is for a SASL mechanism; it seems like you will have difficulty distinguishing between servers in an organization that have a common authentication infrastructure. It seems that we can either: 1) Decide this is OK for SASL and thus OK for GSSAPI. 2) Decide that we don't actually get mutual authentication and remove that claim. 3) Fix the problem. --Sam From owner-ietf-sasl Wed Jul 23 13:00:23 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NK0Nqt067215 for ; Wed, 23 Jul 2003 13:00:23 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NK0Nbc067214 for ietf-sasl-bks; Wed, 23 Jul 2003 13:00:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NK0Mqt067209 for ; Wed, 23 Jul 2003 13:00:22 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h6NK06Gv014020; Wed, 23 Jul 2003 16:00:07 -0400 (EDT) Message-ID: <3F1EE9A1.7010601@oceana.com> Date: Wed, 23 Jul 2003 16:01:37 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Keith Burdis , "Raif S. Naffah" CC: SASL mailing list Subject: SRP security layer output 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: After working through the draft again in detail and attempting to bring the CMU implementation up to date, I found that the documented security layer output is suboptimal. The main problem that I found is that when no layer is active, the raw data still needs to be put into an EOS and then wrapped in a buffer. This means that the raw data would be prepended with three 4-byte lengths (counting the one already required by RFC 2222[bis]). I'm pretty sure that the other mechs that support security layers don't require the raw data to be encoded/decoded when no layer is active. I also don't see the point in wrapping the data segments into EOS and OS even when layers *are* active. Given the fact that SASL already requires the 4-byte length prepended to the output, and we know that the size of the HMAC is fixed, why not just append the HMAC to the raw/encrypted data and send them as plain bytes? The HMAC will always be the last 'hashlen' bytes and the data will always be the first 'inputlen-hashlen' bytes. So, I'm proposing this change to section 5.5 (Note that this eliminates the EOS data element from the spec): CP IP RD Peer sends/receives I I I bytes(p) I A I bytes(p) | IALG(Ki)( bytes(p) ) I A A bytes(p) | IALG(Ki)( bytes(p) | bytes(q) ) A I I bytes(c) A A I bytes(c) | IALG(Ki)( bytes(c) ) A A A bytes(c) | IALG(Ki)( bytes(c) | bytes(q) ) This allows applications and/or SASL implementations to short-circuit the no layer case (output = input) and potentially eliminates buffer copies resulting from the data wrapping. Also, with regards to the table, I think it makes it easier to read if the inactive layers are shown without any symbol (eg, remove the 'I's). Regards, Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Thu Jul 24 14:37:51 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OLbpqt074394 for ; Thu, 24 Jul 2003 14:37:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OLbpbB074393 for ietf-sasl-bks; Thu, 24 Jul 2003 14:37:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OLbhqt074363 for ; Thu, 24 Jul 2003 14:37:43 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id D95B7152495; Thu, 24 Jul 2003 17:37:30 -0400 (EDT) To: Ken Murchison Cc: Keith Burdis , "Raif S. Naffah" , SASL mailing list Subject: Re: SRP security layer output References: <3F1EE9A1.7010601@oceana.com> From: Sam Hartman Date: Thu, 24 Jul 2003 17:37:30 -0400 In-Reply-To: <3F1EE9A1.7010601@oceana.com> (Ken Murchison's message of "Wed, 23 Jul 2003 16:01:37 -0400") 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: The SASL mech should never use section 5 with all layers disabled. If the SASL mech is used without security layers, the application will never even pass the data to the SASL implementation. From owner-ietf-sasl Thu Jul 24 17:35:26 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6P0ZQqt084194 for ; Thu, 24 Jul 2003 17:35:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6P0ZQ50084193 for ietf-sasl-bks; Thu, 24 Jul 2003 17:35:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6P0ZOqt084121 for ; Thu, 24 Jul 2003 17:35:24 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (ny-kenton4a-a-83.buf.adelphia.net [24.51.28.83]) (authenticated bits=0) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h6P0ZAGw024653 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 24 Jul 2003 20:35:11 -0400 (EDT) Message-ID: <3F207B3B.3030402@oceana.com> Date: Thu, 24 Jul 2003 20:35:07 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. 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,pdf MIME-Version: 1.0 To: Sam Hartman CC: Keith Burdis , "Raif S. Naffah" , SASL mailing list Subject: Re: SRP security layer output References: <3F1EE9A1.7010601@oceana.com> In-Reply-To: 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: > The SASL mech should never use section 5 with all layers disabled. If > the SASL mech is used without security layers, the application will > never even pass the data to the SASL implementation. I agree, but that's not what is stated in Section 5 paragraph 3: "The data always passes through this three-stage filter, though any of the stages may be inactive. Only when a stage is active would the output be different from the input. In other words, if a stage is inactive, the octet sequence at the output side is an exact duplicate of the same sequence at the input side." This statement and the summary in Section 5.5 leads me to believe that the intention is to encode the data whether a security layer exists or not. I disagree with this (and the needless wrapping of the data elements), which is why I proposed my change. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Fri Jul 25 10:05:55 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PH5tqt071736 for ; Fri, 25 Jul 2003 10:05:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PH5tx0071735 for ietf-sasl-bks; Fri, 25 Jul 2003 10:05:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-TWO-SIXTY-TWO.MIT.EDU [18.187.6.7]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PH5rqt071730 for ; Fri, 25 Jul 2003 10:05:53 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 91CEC152496; Fri, 25 Jul 2003 13:05:52 -0400 (EDT) To: Ken Murchison Cc: Keith Burdis , "Raif S. Naffah" , SASL mailing list Subject: Re: SRP security layer output References: <3F1EE9A1.7010601@oceana.com> <3F207B3B.3030402@oceana.com> From: Sam Hartman Date: Fri, 25 Jul 2003 13:05:52 -0400 In-Reply-To: <3F207B3B.3030402@oceana.com> (Ken Murchison's message of "Thu, 24 Jul 2003 20:35:07 -0400") 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: >>>>> "Ken" == Ken Murchison writes: Ken> I agree, but that's not what is stated in Section 5 paragraph Ken> 3: Ken> "The data always passes through this three-stage filter, Ken> though any of the stages may be inactive. Only when a stage Ken> is active would the output be different from the input. In That's true only so long as section 5 is being referenced. Any other reading implies that this mechanism spec updates the base SASL spec. But I agree that the section on SASL should be clarified. From owner-ietf-sasl Fri Jul 25 13:07:03 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PK73qt084848 for ; Fri, 25 Jul 2003 13:07:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PK73ZI084847 for ietf-sasl-bks; Fri, 25 Jul 2003 13:07:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PK72qt084842 for ; Fri, 25 Jul 2003 13:07:02 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 282C4152496; Fri, 25 Jul 2003 16:06:48 -0400 (EDT) To: ietf-sasl@imc.org Subject: Draft minutes Message-Id: <20030725200648.282C4152496@konishi-polis.mit.edu> Date: Fri, 25 Jul 2003 16:06:48 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please send in comments or corrections by next Tuesday. I will send in for proceedings shortly after that point. IETF SASL WG meeting Minutes ========================== Tuesday 15 July 2003 3:45pm chairs: Sam Hartman Kurt Zeilenga scribe: Luke Howard 2222bis ======= - Alexei noted that he has published a subsequent revision of 2222bis; minor editorial issues remain - Clarification of empty authorization identities - Alexei will do a final revision of the document in the first week of August after which it can go to last call saslprep ======== - Sam noted that current belief is that this will meet the needs of the Kerberos community - The saslprep document is to be revised to include informational mapping tables but is otherwise ready for last call. New revision is expected shortly after the meeting and the last call will follow shortly after it is announced. DIGEST-MD5 ========== - DIGEST-MD5: Alexei noted that since the last revision he has made the following changes: - Clarifications regarding character sets and authorization vs authentication identities - reference to saslprep the last revision has been updated - Clarified RC4 cipher state is not reset between packets - merged AES cipher document with this one - no changes to solve the AES CBC mod attack: requested text be contributed once a solution is found. - The working group decided that AES for digest-md5 will use random IVs rather than counter mode. Counter mode is harder to implement correctly. - Questions from Sam regarding mandatory to implement ciphers: what should it be (if one is not already required)? - Sam believes there will be interest in making RC4 mandatory to implement because it is implemented now; there is no security reason to not do so that he was aware of - Kurt noted a question as to whether security layers were mandatory to implement; not wearing his chair hat he suggested that at least integrity should be mandatory, Alexei noted that many mail clients do authentication only - Chris Newman suggested that layers should not be mandatory because we already have TLS; suggest that vendors may remove support for DIGEST-MD5 entirely due to engineering cost of implementing layers - Kurt suggested SHOULD implement integrity and that security considerations should note that you are subject to MITM without TLS or layers - Noted that CRAM-MD5 is subject to the "evil server" attach which DIGEST-MD5 is not because there is a client nonce; also DIGEST-MD5 being compatible with HTTP digest has advantages. ie. there are sufficient advantages over CRAM-MD5 in spite of the lack of layers being mandatory to implement - Sam asked for consensus for deprecating both DES and triple DES. There were no objections, nor to taking them out of the document. Sam suggested that we note in the Security Considerations or Changes Since section as to why these were deprecated (preference for latter section) GSSAPI ====== - Sam noted draft was "eaten by the secretariat" - Plan is to move forward on it -- 00 to appear "soon" CRAM-MD5 ======== - A version with saslprep references is available SASL Applicability Statement ============================ - Keith Burdis agreed to submit an SASL applicability statement as an individual submission. His document will include comparisons of the various sasl mechanisms and their security properties. Sam agreed to propose an outline for the document. The working group will discuss rechartering to include this document after the first revision. From owner-ietf-sasl Tue Jul 1 04:23:53 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61BNrFK046736 for ; Tue, 1 Jul 2003 04:23:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61BNrNH046735 for ietf-sasl-bks; Tue, 1 Jul 2003 04:23:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61BNqFK046730 for ; Tue, 1 Jul 2003 04:23:53 -0700 (PDT) (envelope-from nsyracus@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 HAA07340; Tue, 1 Jul 2003 07:23:50 -0400 (EDT) Message-Id: <200307011123.HAA07340@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-rfc2831bis-02.txt Date: Tue, 01 Jul 2003 07:23:50 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Using Digest Authentication as a SASL Mechanism Author(s) : P. Leach, C. Newman, A. Melnikov Filename : draft-ietf-sasl-rfc2831bis-02.txt Pages : 39 Date : 2003-6-30 This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2831bis-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2831bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-30151553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2831bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-30151553.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Tue Jul 1 04:22:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61BMYFK046652 for ; Tue, 1 Jul 2003 04:22:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61BMY7W046651 for ietf-sasl-bks; Tue, 1 Jul 2003 04:22:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61BMWFK046646 for ; Tue, 1 Jul 2003 04:22:32 -0700 (PDT) (envelope-from nsyracus@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 HAA06867; Tue, 1 Jul 2003 07:22:29 -0400 (EDT) Message-Id: <200307011122.HAA06867@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-sasl@imc.org, ietf-http-wg@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-nystrom-http-sasl-07.txt Date: Tue, 01 Jul 2003 07:22:28 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SASL in HTTP/1.1 Author(s) : M. Nystrom, A. Melnikov Filename : draft-nystrom-http-sasl-07.txt Pages : 33 Date : 2003-6-30 This memo suggest the use of SASL [RFC2222] as a framework to enable the use of strong authentication mechanisms in http/1.1 [RFC2616], and defines one approach to accomplish this. Please send comments on this document to the relevant mailing lists, e.g. ietf-sasl@imc.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-07.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-nystrom-http-sasl-07.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-nystrom-http-sasl-07.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-6-30151300.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nystrom-http-sasl-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-nystrom-http-sasl-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-30151300.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Tue Jul 1 04:23:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61BNnFK046726 for ; Tue, 1 Jul 2003 04:23:49 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61BNnDl046725 for ietf-sasl-bks; Tue, 1 Jul 2003 04:23:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61BNmFK046720 for ; Tue, 1 Jul 2003 04:23:48 -0700 (PDT) (envelope-from nsyracus@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 HAA07324; Tue, 1 Jul 2003 07:23:45 -0400 (EDT) Message-Id: <200307011123.HAA07324@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-01.txt Date: Tue, 01 Jul 2003 07:23:45 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-01.txt Pages : 18 Date : 2003-6-30 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-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-rfc2222bis-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-rfc2222bis-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-6-30151543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-30151543.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Tue Jul 1 07:02:06 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61E26FK055184 for ; Tue, 1 Jul 2003 07:02:06 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61E240x055183 for ietf-sasl-bks; Tue, 1 Jul 2003 07:02:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61E23FK055174 for ; Tue, 1 Jul 2003 07:02:03 -0700 (PDT) (envelope-from leg@andrew.cmu.edu) Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.12.9/8.12.6) with ESMTP id h61E1sXM006527; Tue, 1 Jul 2003 07:01:54 -0700 Received: from mirapoint.corp.google.com (IDENT:mirapoint@mirapoint.corp.google.com [10.32.0.80]) by moma.corp.google.com (8.12.9/8.12.3) with ESMTP id h61E1sff029572; Tue, 1 Jul 2003 07:01:54 -0700 Received: from andrew.cmu.edu (dunbar.corp.google.com [10.2.2.110]) by mirapoint.corp.google.com (Mirapoint Messaging Server MOS 3.3.5-GR) with ESMTP id ABT15494 (AUTH leg); Tue, 1 Jul 2003 07:01:53 -0700 (PDT) Message-ID: <3F019450.8020808@andrew.cmu.edu> Date: Tue, 01 Jul 2003 10:01:52 -0400 From: Larry Greenfield User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Guenther CC: Rob Siemborski , Greg Hudson , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <200307010435.h614Zgf12987@katroo.Sendmail.COM> In-Reply-To: <200307010435.h614Zgf12987@katroo.Sendmail.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: >Rob Siemborski writes: >... > > >>This works, until an application is running using an incompatible >>threading API (see Larry's answer to my earlier question). >> >> >I knew I should have replied to Larry's answer. I find his example >unconvincing. He has suggested that there may exist a cooperative >threading library running on a system that has a system level threading >implementation and that intercepts blocking I/O calls (i.e., supplies >symbols like connect(), read(), etc) such that it intercepts the calls >of unmodified libraries, but that *doesn't* intercept calls to the >system's threading primitives. (If that's not what you're suggesting, >Larry, please correct me.) > This appears to be an accurate description of the GNU Pth library using the "hard system call mapping". (I base this off of the documentation and not first hand experience.) Pth is a popular and frequently used threading library. Larry From owner-ietf-sasl Tue Jul 1 07:12:54 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61ECsFK055913 for ; Tue, 1 Jul 2003 07:12:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61ECsgC055912 for ietf-sasl-bks; Tue, 1 Jul 2003 07:12:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61ECqFK055906 for ; Tue, 1 Jul 2003 07:12:52 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from BBOARD.andrew.cmu.edu (BBOARD.andrew.cmu.edu [128.2.10.89]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h61ECquO006725; Tue, 1 Jul 2003 10:12:52 -0400 Date: Tue, 1 Jul 2003 10:12:53 -0400 (EDT) From: Rob Siemborski To: Greg Hudson cc: ietf-sasl@imc.org Subject: Re: Using SASL C API from a library In-Reply-To: <1057032466.12524.317.camel@error-messages.mit.edu> Message-ID: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.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 Tue, 1 Jul 2003, Greg Hudson wrote: > > Unless I am misremembering, this is basically what we discussed in San > > Francisco (I thought I had mentioned that). > > (The minutes do not appear to document any discussion of the SASL C API, > incidentally.) Since its not a charter item, it wasn't discussed in the formal WG meeting. I think Alexey has notes from when a few of us sat around discussing it though. > Previously, you said "it can be solved by not using global callbacks > except in the outermost application," which is very different from "not > using global callbacks at all." > > > Note that this is difficult for situations such as the getopt callback > > where path information to loadable modules (or similar information that is > > requried for the library to initialize) may need to be obtained. > > There is really no limit to the number of awful things you could justify > putting into the API if you want to satisfy every possible foible of a > back-end library. [snip] You don't need to satisfy every possible one, but let's at least try to anticipate reasonable desires of the implementors. > So, unless you can demonstrate a present practical issue, I don't think > this argument is even vaguely compelling. Kerberos mechanisms need a path to a srvtab or keytab. Perhaps shared secret mechanisms need a path to a database of shared secrets. Perhaps one of the worse examples (though one of the most useful) is a list of mechanisms to limit what the library advertises. The good news here is that most of these are (or can be made to be) connection-context specific. Ones that potentially need to be supported by a global getopt callback really significantly fewer. > Franky, the getopt callback is a great big hole in the spec for > unspecified behavior (both mechanism-specific and > implementation-specific), since there is no standardization of what the > options mean. Presumably the idea is that you would provide the answers > from a configuration file or from command-line options, giving a sort of > direct communications channel between the user and the SASL library or > specific mechanism. That may sound attractive to implementors, but it's > a totally unacceptable idea, because it's impossible to document such a > config file or command-line syntax without knowing the intimate (and > version-specific) details of your SASL implementation, and because it's > impossible to provide reasonable answers in a situation where a config > file or command line doesn't make sense. The application doesn't have to understand the options its handing to the library, only the user does. And the user can have access to implementation-specific information about the library. Sure, the library can also just access a configuration file to get the information it needs, but then how does the user supply the path the the configuration file? I'm quite certain that having a fixed path to a configuration file isn't what users are looking for. And being able to combine SASL options with application options in one place is a usability improvement. Implementations of the SASL API will require configuration options to function properly, we shouldn't deny them a reasonable way to get that information in a standard way, even if the information itself is implementation dependent. -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 Tue Jul 1 08:27:29 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61FRTFK060498 for ; Tue, 1 Jul 2003 08:27:29 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61FRTD9060497 for ietf-sasl-bks; Tue, 1 Jul 2003 08:27:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61FRSFK060489 for ; Tue, 1 Jul 2003 08:27:28 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h61FRS9W001128; Tue, 1 Jul 2003 11:27:28 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h61FRRjO013920; Tue, 1 Jul 2003 11:27:27 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h61FRRU8006774; Tue, 1 Jul 2003 11:27:27 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h61FRQwU023364; Tue, 1 Jul 2003 11:27:26 -0400 Subject: Re: Using SASL C API from a library From: Greg Hudson To: Rob Siemborski Cc: ietf-sasl@imc.org In-Reply-To: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057073245.12524.334.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 01 Jul 2003 11:27:26 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2003-07-01 at 10:12, Rob Siemborski wrote: > > So, unless you can demonstrate a present practical issue, I don't think > > this argument is even vaguely compelling. > The good news here is that most of these are (or can be made to be) > connection-context specific. Ones that potentially need to be supported > by a global getopt callback really significantly fewer. Certainly it should be possible for krb5, since krb5 does not use global state. (It also does not allow the caller to pass a path to find krb5.conf.) > Sure, the library can also just access a configuration file to get the > information it needs, but then how does the user supply the path the the > configuration file? I'm quite certain that having a fixed path to a > configuration file isn't what users are looking for. I believe this is argument from fantasy. I don't think there's any back-end mechanism library which asks for this kind of information from the calling code. They all uses fixed paths, possibly overridden by environment variables which the calling code is not expected to tamper with. > And being able to combine SASL options with application options in one > place is a usability improvement. Options required for a SASL library itself should be nailed down by the spec or not subject to configuration by the caller. (The plugin dir, for instance, should be found in a fixed location or via an environment variable; there's no reason for SASL to introduce a completely new override mechanism.) > Implementations of the SASL API will require configuration options to > function properly, we shouldn't deny them a reasonable way to get that > information in a standard way, even if the information itself is > implementation dependent. Once again, you've made an argument which (I believe) no other standardized API makes, and provided no specific examples to back it up. From owner-ietf-sasl Wed Jul 2 09:36:39 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62GadFK068828 for ; Wed, 2 Jul 2003 09:36:39 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62GadEW068827 for ietf-sasl-bks; Wed, 2 Jul 2003 09:36:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62GacFK068822 for ; Wed, 2 Jul 2003 09:36:38 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 09646151582; Wed, 2 Jul 2003 12:36:25 -0400 (EDT) To: ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> From: Sam Hartman Date: Wed, 02 Jul 2003 12:36:25 -0400 In-Reply-To: (Rob Siemborski's message of "Mon, 30 Jun 2003 14:50:44 -0400 (EDT)") 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: >>>>> "Rob" == Rob Siemborski writes: Rob> On Sun, 29 Jun 2003, Greg Hudson wrote: >> It seems like a bizarre argument, especially when Unix systems >> converged on the POSIX threads API years and years ago. Rob> Solaris has a non-pthreads threading API. There's no reason Rob> the SASL C API should dictate what threading API to use. It's my understanding that at least in recent Solaris versions, the locks between this API and the pthreads API are compatible. Please correct me if I'm wrong. From owner-ietf-sasl Wed Jul 2 13:34:53 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KYqFK082655 for ; Wed, 2 Jul 2003 13:34:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62KYqUx082654 for ietf-sasl-bks; Wed, 2 Jul 2003 13:34:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KYFFK082613 for ; Wed, 2 Jul 2003 13:34:28 -0700 (PDT) (envelope-from nsyracus@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 QAA13327; Wed, 2 Jul 2003 16:34:12 -0400 (EDT) Message-Id: <200307022034.QAA13327@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-anon-02.txt Date: Wed, 02 Jul 2003 16:34:12 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The Anonymous SASL Mechanism Author(s) : K. Zeilenga Filename : draft-ietf-sasl-anon-02.txt Pages : 9 Date : 2003-7-2 It is common practice on the Internet to permit anonymous access to various services. Traditionally, this has been done with a plain text password mechanism using 'anonymous' as the user name and optional trace information, such as an email address, as the password. As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the Simple Authentication and Security Layer (SASL) framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-anon-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-anon-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-anon-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2162000.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-anon-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-anon-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2162000.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Wed Jul 2 13:34:46 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KYkFK082645 for ; Wed, 2 Jul 2003 13:34:46 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62KYkVA082644 for ietf-sasl-bks; Wed, 2 Jul 2003 13:34:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KYOFK082617 for ; Wed, 2 Jul 2003 13:34:30 -0700 (PDT) (envelope-from nsyracus@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 QAA13350; Wed, 2 Jul 2003 16:34:17 -0400 (EDT) Message-Id: <200307022034.QAA13350@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-plain-02.txt Date: Wed, 02 Jul 2003 16:34:16 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The Plain SASL Mechanism Author(s) : K. Zeilenga Filename : draft-ietf-sasl-plain-02.txt Pages : 8 Date : 2003-7-2 This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols which lack a simple password authentication command. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-plain-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-plain-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-plain-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2162011.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-plain-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-plain-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2162011.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Wed Jul 2 13:35:45 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KZjFK082695 for ; Wed, 2 Jul 2003 13:35:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62KZj6g082694 for ietf-sasl-bks; Wed, 2 Jul 2003 13:35:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KYBFK082612 for ; Wed, 2 Jul 2003 13:34:15 -0700 (PDT) (envelope-from nsyracus@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 QAA13309; Wed, 2 Jul 2003 16:34:07 -0400 (EDT) Message-Id: <200307022034.QAA13309@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-saslprep-03.txt Date: Wed, 02 Jul 2003 16:34:06 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : SASLprep: Stringprep profile for user names and passwords Author(s) : K. Zeilenga Filename : draft-ietf-sasl-saslprep-03.txt Pages : 6 Date : 2003-7-2 This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the 'SASLprep' 'stringprep' profile to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging user names and/or passwords. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-03.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-saslprep-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-saslprep-03.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-7-2161947.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-saslprep-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-saslprep-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161947.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Wed Jul 2 18:53:24 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h631rOFK097002 for ; Wed, 2 Jul 2003 18:53:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h631rO8j097001 for ietf-sasl-bks; Wed, 2 Jul 2003 18:53:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h631rOFK096996 for ; Wed, 2 Jul 2003 18:53:24 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust22.tnt101.lnd4.gbr.da.uu.net [213.116.50.22]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h631utV31115; Wed, 2 Jul 2003 19:56:56 -0600 Message-ID: <3F037BD6.AC4E6681@isode.com> Date: Wed, 02 Jul 2003 18:41:59 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg Hudson CC: Rob Siemborski , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greg Hudson wrote: > > Sure, the library can also just access a configuration file to get the > > information it needs, but then how does the user supply the path the the > > configuration file? I'm quite certain that having a fixed path to a > > configuration file isn't what users are looking for. > > I believe this is argument from fantasy. I don't think there's any > back-end mechanism library which asks for this kind of information from > the calling code. They all uses fixed paths, possibly overridden by > environment variables which the calling code is not expected to tamper > with. > > And being able to combine SASL options with application options in one > > place is a usability improvement. > > Options required for a SASL library itself should be nailed down by the > spec or not subject to configuration by the caller. (The plugin dir, > for instance, should be found in a fixed location or via an environment > variable; there's no reason for SASL to introduce a completely new > override mechanism.) Oh, please. What if my application wants to use a fixes path, but not the one hardcoded in the SASL library? Plus hardcoded paths don't work on certain OSes (e.g. Windows). Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Wed Jul 2 18:53:10 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h631rAFK096986 for ; Wed, 2 Jul 2003 18:53:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h631rAKH096985 for ietf-sasl-bks; Wed, 2 Jul 2003 18:53:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h631r9FK096980 for ; Wed, 2 Jul 2003 18:53:09 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust22.tnt101.lnd4.gbr.da.uu.net [213.116.50.22]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h631udV31109; Wed, 2 Jul 2003 19:56:41 -0600 Message-ID: <3F037AF4.7919F21C@isode.com> Date: Wed, 02 Jul 2003 18:38:12 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Josefsson CC: ietf-sasl@imc.org Subject: Re: Comments on the SASL C API References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon Josefsson wrote: > ... I've added some clarification about multiple SASL tokens in sasl_decode as described by Larry. > Extension: > Here is a writeup on an idea I have received. It might cause some > complications and likely needs more pondering. However, if the > rationale for adding this makes sense to you, I'd appreciate if you > spent the time incorporating the functions. If you are familiar with > the GSS-API, compare this to the gss_export_sec_context and > gss_import_sec_context functions that were added to GSS-API version 2 > (see RFC 2744). I like the idea and had though about something similar myself. The question is if this belong to the base SASL API document or should this be an extension. I would like to hear what other people think about adding this. > 5.2. Exporting and importing security layer state > > Some application environments wishes to separate the initial and > short authentication step from the potentially long lived > application step, where the application uses sasl_encode() and > sasl_decode() to transfer application data. This separation may > be between processes (separation across hosts is more > complicated, as the security layer state is often dependent on > the host address, but still conceivable). The reason for such > separation may be to guarantee that long-term secrets (e.g., > passwords) cannot be recovered by compromising the application > that handles existing session. > > The functions defined in this section allows the application to > export the security layer state associated with a session as an > opaque character string, and later import the opaque character > string. The opaque state typically contains an encryption key, > initialization vectors, what encryption algorithm to use, packet > number etc. > > 5.2.1. sasl_export_security_layer_state function > > Arguments: > sasl_conn_t *conn, > const char **state, > unsigned int *statelen > > Results: > SASL_OK -- Success > SASL_NOTDONE -- Security layer negotiation not finished > > This function exports the security layer state required to > implement the sasl_encode() and sasl_decode() functions after > the state has been imported. The security layer state is an > opaque data string. The state and statelen are filled in with > the opaque state data and its length respectively. If the > security layer negotiation has not finished, SASL_NOTDONE is > returned. After calling this function, the application should > treat the SASL session as concluded and call sasl_dispose(). In > particular, the application MUST NOT call sasl_encode() or > sasl_decode() [XXX sasl_dencode should simply return a error > code when it happens]. The state data is only valid until a > call to sasl_dispose(), and should be copied before calling > sasl_dipose() if necessary. > > 5.2.2. sasl_import_security_layer_state function > > Arguments: > const char *state, > unsigned int statelen > sasl_conn_t **conn, > > Results: > SASL_OK -- Success > SASL_BADPARAM -- Invalid parameter supplied > > This function create a SASL session, for use with sasl_encode(), > sasl_decode() and sasl_dispose() only, from the given security > layer state. The security layer state is an opaque data string, > as returned from sasl_export_security_layer_state(). Cheers, Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Wed Jul 2 18:53:35 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h631rYFK097014 for ; Wed, 2 Jul 2003 18:53:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h631rYnZ097013 for ietf-sasl-bks; Wed, 2 Jul 2003 18:53:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h631rYFK097008 for ; Wed, 2 Jul 2003 18:53:34 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust22.tnt101.lnd4.gbr.da.uu.net [213.116.50.22]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h631vAV31120; Wed, 2 Jul 2003 19:57:11 -0600 Message-ID: <3F037D21.D883D566@isode.com> Date: Wed, 02 Jul 2003 18:47:29 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Siemborski CC: ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: > > Since people have grown silent on the topic, I'll note that no excuse > > has been given for the global callbacks structure, and no answer has > > been given to my argument that library calls to the SASL C API could > > accidentally trigger invocations of the application's global callbacks > > no matter what the library does to guard against this possibility. If > > transition for users of Cyrus SASL is the only concern, then the API > > spec can preserve the parameter as a dummy and mandate that all callers > > must pass NULL, as has been done in Unix with gettimeofday() and the > > timezone parameter. > > Unless I am misremembering, this is basically what we discussed in San > Francisco (I thought I had mentioned that). Yes, this is in my notes. More specifically: 1). Init problem: deprecatate global callbacks. If global callbacks are provided multiple times, this is implementation dependent. 2). Make appname setprop/getprop appname must be NULL in sasl_server_init, if it is called from a library. > Note that this is difficult for situations such as the getopt callback, > where path information to loadable modules (or similar information that is > requried for the library to initialize) may need to be obtained. In this > case (since it is part of the one-time library startup) the application > would need to supply a getopt callback. Since its one-time startup state, > your library couldn't change it if it wanted to. So, where this discussion leaves us? Should I change the document to say that global callbacks must be NULL, except for maybe the getopt callback? Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Wed Jul 2 19:05:09 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63259FK098063 for ; Wed, 2 Jul 2003 19:05:09 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h632593O098062 for ietf-sasl-bks; Wed, 2 Jul 2003 19:05:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63257FK098057 for ; Wed, 2 Jul 2003 19:05:08 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h63257QU012768; Wed, 2 Jul 2003 22:05:07 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h63256pP012527; Wed, 2 Jul 2003 22:05:07 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h63256FJ021029; Wed, 2 Jul 2003 22:05:06 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h63254l8025028; Wed, 2 Jul 2003 22:05:04 -0400 Subject: Re: Using SASL C API from a library From: Greg Hudson To: Alexey Melnikov Cc: ietf-sasl@imc.org In-Reply-To: <3F037BD6.AC4E6681@isode.com> References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057197903.12524.401.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 02 Jul 2003 22:05:04 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 2003-07-02 at 20:41, Alexey Melnikov wrote: > > Options required for a SASL library itself should be nailed down by the > > spec or not subject to configuration by the caller. (The plugin dir, > > for instance, should be found in a fixed location or via an environment > > variable; there's no reason for SASL to introduce a completely new > > override mechanism.) > > Oh, please. What if my application wants to use a fixes path, but not the one > hardcoded in the SASL library? > > Plus hardcoded paths don't work on certain OSes (e.g. Windows). Why would you ever write an application which cares, more than any other application, where a SASL library looks for its plugin directory? Every caller of the SASL library should be in the same position here. Which means the library needs to be able to find its plugins without help from the calling code. Whether that means a fixed path, an environment variable, the registry, or whatever else is up to the library, but asking the calling code to provide that information is of no help. But let's say I'm wrong, and there really is some good reason why the calling code should be helping out. And let's also say that this reason isn't good enough to make the plugin directory part of the standard SASL C API. What value is there in half-standardizing the interface through which the library gets this information? If some application needs this non-standard functionality and therefore can only use (let's say) the Cyrus implementation, then the Cyrus implementation can add its own non-standard function to specify the plugin directory. From owner-ietf-sasl Wed Jul 2 20:30:09 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h633U9FK000923 for ; Wed, 2 Jul 2003 20:30:09 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h633U8Y1000922 for ietf-sasl-bks; Wed, 2 Jul 2003 20:30:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h633U7FK000917 for ; Wed, 2 Jul 2003 20:30:07 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h633U6ST018367 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 3 Jul 2003 05:30:07 +0200 To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Comments on the SASL C API References: <3F037AF4.7919F21C@isode.com> From: Simon Josefsson X-Payment: hashcash 1.2 0:030703:Alexey.Melnikov@isode.com:eaeec8eca266056f X-Hashcash: 0:030703:Alexey.Melnikov@isode.com:eaeec8eca266056f X-Payment: hashcash 1.2 0:030703:ietf-sasl@imc.org:b8615009abdb22a5 X-Hashcash: 0:030703:ietf-sasl@imc.org:b8615009abdb22a5 Date: Thu, 03 Jul 2003 05:30:06 +0200 In-Reply-To: <3F037AF4.7919F21C@isode.com> (Alexey Melnikov's message of "Wed, 02 Jul 2003 18:38:12 -0600") 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 X-Spam-Status: No, hits=-29.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > I've added some clarification about multiple SASL tokens in sasl_decode as > described by Larry. Thank you, and also to Greg and Larry who provided insight. The problem had a simple solution, but it wasn't really obvious [to me], so additional text would not hurt. Perhaps it can even be useful to application writers, so they know sasl_decode() could return data that is the concatenation of output from more than one call to sasl_encode(). It appears that this could affect the choice of buffer sizes. From owner-ietf-sasl Thu Jul 3 06:51:38 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63DpbFK058744 for ; Thu, 3 Jul 2003 06:51:37 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63Dpb9q058743 for ietf-sasl-bks; Thu, 3 Jul 2003 06:51:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63DpaFK058738 for ; Thu, 3 Jul 2003 06:51:36 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h63DpZuO006317; Thu, 3 Jul 2003 09:51:35 -0400 Date: Thu, 3 Jul 2003 09:51:35 -0400 (EDT) From: Rob Siemborski To: Greg Hudson cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library In-Reply-To: <1057197903.12524.401.camel@error-messages.mit.edu> Message-ID: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.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 Wed, 2 Jul 2003, Greg Hudson wrote: > But let's say I'm wrong, and there really is some good reason why the > calling code should be helping out. And let's also say that this reason > isn't good enough to make the plugin directory part of the standard SASL > C API. What value is there in half-standardizing the interface through > which the library gets this information? If some application needs this > non-standard functionality and therefore can only use (let's say) the > Cyrus implementation, then the Cyrus implementation can add its own > non-standard function to specify the plugin directory. Are you saying its better to have NO standard way to get configuration information into the library fromt he application? Thus, if I want an application to work with two types of libraries, I have to provide (in hard code) perhaps a callback for SASL_NONSTANARD_CB_PATHNAME and SASL_NONSTANDARD_CB_PATH_TO_PLUGINS just to work with two implementation? Worse: what if these two implementations define the same values for these two callbacks! The getopt callback supplys a standard way to get this information from the application. Since presumably the application is looking up this information in its own config files, the user can read the documentation for their SASL implementation and decide if they need to set the SASL option "pathname" or "path_to_plugins". This can be done without needing to change the code to the application. -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 Thu Jul 3 08:47:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63Flwqt000231 for ; Thu, 3 Jul 2003 08:47:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63Flw5N000230 for ietf-sasl-bks; Thu, 3 Jul 2003 08:47:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63Floqt000223 for ; Thu, 3 Jul 2003 08:47:57 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust128.tnt24.lnd4.gbr.da.uu.net [62.188.151.128]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h63FkmV04797; Thu, 3 Jul 2003 09:46:51 -0600 Message-ID: <3F043077.BD141F4F@isode.com> Date: Thu, 03 Jul 2003 07:32:39 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Josefsson CC: ietf-sasl@imc.org Subject: Re: Comments on the SASL C API References: <3F037AF4.7919F21C@isode.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon Josefsson wrote: > Alexey Melnikov writes: > > > I've added some clarification about multiple SASL tokens in sasl_decode as > > described by Larry. > > Thank you, and also to Greg and Larry who provided insight. The > problem had a simple solution, but it wasn't really obvious [to me], > so additional text would not hurt. Perhaps it can even be useful to > application writers, so they know sasl_decode() could return data that > is the concatenation of output from more than one call to > sasl_encode(). It appears that this could affect the choice of buffer > sizes. sasl_decode allocates or returns own buffer, so the caller shouldn't worry about buffer sizes. Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Thu Jul 3 10:04:32 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63H4Vqt006936 for ; Thu, 3 Jul 2003 10:04:31 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63H4VqB006935 for ietf-sasl-bks; Thu, 3 Jul 2003 10:04:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63H4Uqt006929 for ; Thu, 3 Jul 2003 10:04:31 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h63H4TmK015407; Thu, 3 Jul 2003 13:04:29 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h63H4SEk025075; Thu, 3 Jul 2003 13:04:28 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h63H4SFJ009148; Thu, 3 Jul 2003 13:04:28 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h63H4RcJ025661; Thu, 3 Jul 2003 13:04:27 -0400 Subject: Re: Using SASL C API from a library From: Greg Hudson To: Rob Siemborski Cc: ietf-sasl@imc.org In-Reply-To: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057251866.12524.430.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 03 Jul 2003 13:04:27 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-07-03 at 09:51, Rob Siemborski wrote: > Are you saying its better to have NO standard way to get configuration > information into the library fromt he application? Absolutely. The vast majority of APIs contain no such mechanism, because a library should be able to do its job without creating such a mechanism. If for some reason the library needs configuration, it can get it via its own configuration files, which it can find through mechanisms not involving the calling code (fixed paths, environment variables, the registry, etc.). The only exception class tends to be gui toolkits, which usually want to take over the command line by accepting and modifying argc and argv. I'm ambivalent about this practice (it makes it harder to document the command-line syntax of programs using the gui toolkit, but it's hard to imagine doing without it given the variety of standard command-line arguments affecting the toolkit), but it's not terribly onerous because a GUI toolkit tends to dominate the scope and structure of an application. Not so with a SASL library. > Thus, if I want an > application to work with two types of libraries, I have to provide (in > hard code) perhaps a callback for SASL_NONSTANARD_CB_PATHNAME and > SASL_NONSTANDARD_CB_PATH_TO_PLUGINS just to work with two implementation? If we are talking about an application providing this information for its own reasons, then it's already sunk; the SASL API says nothing about plugin paths, you don't know what option name would be involved, and the implementation might not even use plugins. (And of course, if the application is providing such information for its own reasons, it probably cares about the back-end plugin interface, which isn't specified at all.) But, of course, the specifiers are not envisioning an application providing this information for its own reasons; they are envisioning an application blindly (no stigma here) passing along user configuration, as reflected here: > The getopt callback supplys a standard way to get this information from > the application. Since presumably the application is looking up this > information in its own config files, the user can read the documentation > for their SASL implementation and decide if they need to set the SASL > option "pathname" or "path_to_plugins". This can be done without needing > to change the code to the application. We're going around in circles on this point. I'll skip the part where I argue against this idea at the end of and go to the part where you respond in with (among discussions of fixed paths versus other ways of finding a config file, which we've also talked about at length): And being able to combine SASL options with application options in one place is a usability improvement. which is another puzzling argument. Most discussion of usability revolves around GUI interfaces, and it is impossible to create a non-degenerate GUI configuration interface for options you know nothing about. The best you can do is provide a registry-like interface where the user can manipulate key-value pairs, which is only one step away from editing text files. But even if we're talking about usability among the tiny (percentagewise) population of users who are comfortable editing configuration files, I don't see the benefit. Why would I want to have a single configuration whose meaning is split over two or more different pieces of documentation? Wouldn't I like my configuration files to have nicely commented templates? (That would be logistically difficult for configuration files which span abstraction barriers like you envision.) And if I want to change where (say) Cyrus SASL looks for its plugins, why would I want to have to do that for every application which uses Cyrus SASL, instead of doing it in one place? From owner-ietf-sasl Thu Jul 3 10:15:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63HFXqt007884 for ; Thu, 3 Jul 2003 10:15:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63HFXIp007883 for ietf-sasl-bks; Thu, 3 Jul 2003 10:15:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63HFWqt007877 for ; Thu, 3 Jul 2003 10:15:32 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h63HFWuO019390; Thu, 3 Jul 2003 13:15:32 -0400 Date: Thu, 3 Jul 2003 13:15:31 -0400 (EDT) From: Rob Siemborski To: Greg Hudson cc: ietf-sasl@imc.org Subject: Re: Using SASL C API from a library In-Reply-To: <1057251866.12524.430.camel@error-messages.mit.edu> Message-ID: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.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 Thu, 3 Jul 2003, Greg Hudson wrote: > And if I want to change where (say) Cyrus SASL looks for its plugins, > why would I want to have to do that for every application which uses > Cyrus SASL, instead of doing it in one place? Nothing prevents the library from having defaults, or looking at environment variables, or reading from /dev/random to gain the information otherwise provided by getopt in other ways. However, in your scenario all the applications running on a system need to share the same global configuration with no possibility of making application-specific changes. Which really isn't acceptable. -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 Thu Jul 3 10:25:32 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63HPWqt008221 for ; Thu, 3 Jul 2003 10:25:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63HPW45008220 for ietf-sasl-bks; Thu, 3 Jul 2003 10:25:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63HPVqt008212 for ; Thu, 3 Jul 2003 10:25:31 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h63HPR2A004231; Thu, 3 Jul 2003 13:25:30 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h63HKREk026630; Thu, 3 Jul 2003 13:20:28 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h63HKRFJ009668; Thu, 3 Jul 2003 13:20:27 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h63HKQ57025753; Thu, 3 Jul 2003 13:20:26 -0400 Subject: Re: Using SASL C API from a library From: Greg Hudson To: Rob Siemborski Cc: ietf-sasl@imc.org In-Reply-To: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057252825.12524.435.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 03 Jul 2003 13:20:26 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-07-03 at 13:15, Rob Siemborski wrote: > However, in your scenario all the applications running on a system need to > share the same global configuration with no possibility of making > application-specific changes. Which really isn't acceptable. Why not? There is no application-specific configuration for krb5, or for the resolver, or for a host of other libraries. (You can, of course, hack it up using environment variables and alternate config files, but people rarely seem to.) If you actually can come up with a practical reason to have application-specific configuration for a SASL library (a concept which doesn't make a lot of sense when SASL is being driven from another library), then it is *still* better to handle this from a SASL-specific configuration file, using options keyed off the application name, because then it's possible to write documentation and GUI tools which understand everything about the config file, unlike in your scheme. From owner-ietf-sasl Thu Jul 3 11:35:04 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63IZ4qt013617 for ; Thu, 3 Jul 2003 11:35:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63IZ4mS013616 for ietf-sasl-bks; Thu, 3 Jul 2003 11:35:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63IZ3qt013611 for ; Thu, 3 Jul 2003 11:35:03 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h63IZ3uO023946; Thu, 3 Jul 2003 14:35:03 -0400 Date: Thu, 3 Jul 2003 14:35:02 -0400 (EDT) From: Rob Siemborski To: ietf-sasl@imc.org cc: kurt@OpenLDAP.org Subject: Re: I-D ACTION:draft-ietf-sasl-anon-02.txt In-Reply-To: <200307022034.QAA13327@ietf.org> Message-ID: References: <200307022034.QAA13327@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 Wed, 2 Jul 2003 Internet-Drafts@ietf.org wrote: > Title : The Anonymous SASL Mechanism > Author(s) : K. Zeilenga > Filename : draft-ietf-sasl-anon-02.txt >> ...not part of SASL itself. Newer profiles of SASL will include the client message with the AUTHENTICATE command itself so the extra round trip below (the server response with an empty "+ ") can be eliminated. << Seems to indicate a requirement on new SASL profiles, which is outside of the scope of the document. However, it is reasonable to add some clarification that the extra round trip is an artifact of the IMAP profile. How about something more like: ...not part of SASL itself. Additionally, protocols with SASL profiles permitting an initial client response will be able to avoid the extra round trip below (the server response with an empty "+ "). -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 Thu Jul 3 15:29:47 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63MTlqt025102 for ; Thu, 3 Jul 2003 15:29:47 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63MTlte025101 for ietf-sasl-bks; Thu, 3 Jul 2003 15:29:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63MTkqt025096 for ; Thu, 3 Jul 2003 15:29:46 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust9.tnt14.lnd4.gbr.da.uu.net [62.188.143.9]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h63MXFV08159; Thu, 3 Jul 2003 16:33:16 -0600 Message-ID: <3F04ADD2.31E16D8B@isode.com> Date: Thu, 03 Jul 2003 16:27:30 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg Hudson CC: Rob Siemborski , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greg Hudson wrote: > On Thu, 2003-07-03 at 09:51, Rob Siemborski wrote: > > Are you saying its better to have NO standard way to get configuration > > information into the library fromt he application? > > Absolutely. The vast majority of APIs contain no such mechanism, > because a library should be able to do its job without creating such a > mechanism. If for some reason the library needs configuration, it can > get it via its own configuration files, which it can find through > mechanisms not involving the calling code (fixed paths, environment > variables, the registry, etc.). I am afraid I disagree. Centralizing all configuration for an application in one place might be a good (and required) thing. > The only exception class tends to be gui toolkits, which usually want to > take over the command line by accepting and modifying argc and argv. > I'm ambivalent about this practice (it makes it harder to document the > command-line syntax of programs using the gui toolkit, but it's hard to > imagine doing without it given the variety of standard command-line > arguments affecting the toolkit), but it's not terribly onerous because > a GUI toolkit tends to dominate the scope and structure of an > application. Not so with a SASL library. > > > Thus, if I want an > > application to work with two types of libraries, I have to provide (in > > hard code) perhaps a callback for SASL_NONSTANARD_CB_PATHNAME and > > SASL_NONSTANDARD_CB_PATH_TO_PLUGINS just to work with two implementation? > > If we are talking about an application providing this information for > its own reasons, then it's already sunk; the SASL API says nothing about > plugin paths, you don't know what option name would be involved, and the > implementation might not even use plugins. (And of course, if the > application is providing such information for its own reasons, it > probably cares about the back-end plugin interface, which isn't > specified at all.) > > But, of course, the specifiers are not envisioning an application > providing this information for its own reasons; they are envisioning an > application blindly (no stigma here) passing along user configuration, > as reflected here: Ok people. I am afraid we are starting a religious war at this point and this is not going to do us any good. So, how about making some constructive suggestions. How about the following: 1). libraries MUST NOT specify callbacks when calling sasl_client_init/sasl_server_init. Global callbacks are thus deprecated. 2). a new function is added to set getopt callback. An application that doesn't care about getopt, will not call this function. If this callback is not set, the SASL library will use reasonable defaults or get the required information from own config file/environment/registry/whatever. 3). one of the getopt options is a plugin directory. If the application doesn't care, its getopt callback will fail to return the value for this option. The SASL library will choose a reasonable default in this case. If the SASL library doesn't support plugins, it will not care about this option. I believe this is how it works now anyway (except for new function for setting getopt). Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Thu Jul 3 15:44:10 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63MiAqt026210 for ; Thu, 3 Jul 2003 15:44:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63MiAs4026209 for ietf-sasl-bks; Thu, 3 Jul 2003 15:44:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63Mi8qt026203 for ; Thu, 3 Jul 2003 15:44:09 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h63MiAuO031643; Thu, 3 Jul 2003 18:44:10 -0400 Date: Thu, 3 Jul 2003 18:44:10 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: Greg Hudson , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library In-Reply-To: <3F04ADD2.31E16D8B@isode.com> Message-ID: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 3 Jul 2003, Alexey Melnikov wrote: > Ok people. I am afraid we are starting a religious war at this point and > this is not going to do us any good. I agree. > So, how about making some constructive suggestions. How about the following: > 1). libraries MUST NOT specify callbacks when calling > sasl_client_init/sasl_server_init. > Global callbacks are thus deprecated. > > 2). a new function is added to set getopt callback. An application that > doesn't care about getopt, will not call this function. If this callback > is not set, the SASL library will use reasonable defaults or get the > required information from own config file/environment/registry/whatever. > > 3). one of the getopt options is a plugin directory. If the application doesn't > care, its getopt callback will fail to return the value for this option. The > SASL library will choose a reasonable default in this case. If the SASL library > doesn't support plugins, it will not care about this option. This is worse than the global callbacks scenario with libraries forbidden from setting global callbaks, since in this situation a libary can call the magic new function to set the getopt() callback. I don't see how this is better than allowing a getopt() callback to be set by the application, but not by libraries in the call to sasl_xxx_init(). Even if we forbid libraries from calling this new function, the situation is worse than allowing applications to set a getopt callback in their call to sasl_xxx_init(), as it requires changes from current practice. > I believe this is how it works now anyway (except for new function for setting > getopt). Not quite true, this requires standardizing the name of an option, as well. -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 Thu Jul 3 15:43:01 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63Mh1qt026128 for ; Thu, 3 Jul 2003 15:43:01 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63Mh1jd026127 for ietf-sasl-bks; Thu, 3 Jul 2003 15:43:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63Mh0qt026122 for ; Thu, 3 Jul 2003 15:43:00 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h63Mh16i028898; Thu, 3 Jul 2003 18:43:01 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h63Mh0qM022391; Thu, 3 Jul 2003 18:43:01 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h63MgvFJ018404; Thu, 3 Jul 2003 18:42:58 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h63MgunK026152; Thu, 3 Jul 2003 18:42:56 -0400 Subject: Re: Using SASL C API from a library From: Greg Hudson To: Alexey Melnikov Cc: ietf-sasl@imc.org In-Reply-To: <3F04ADD2.31E16D8B@isode.com> References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057272175.12524.444.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 03 Jul 2003 18:42:56 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-07-03 at 18:27, Alexey Melnikov wrote: > So, how about making some constructive suggestions. How about the following: > 1). libraries MUST NOT specify callbacks when calling > sasl_client_init/sasl_server_init. > Global callbacks are thus deprecated. You seem to leave open the question of whether applications are allowed to specify callbacks. Was that intentional? (As I've mentioned before, if applications are allowed to set global callbacks, then a library using SASL cannot guard against accidentally triggering the application global callbacks.) > 2). a new function is added to set getopt callback. An application that doesn't > care about getopt, will not call this function. Well, as everybody knows, my religion does not include such a device, but global state is generally not burdensome as long as it's (completely) optional. So I won't scream and yell about it. From owner-ietf-sasl Fri Jul 4 05:18:25 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64CIPqt085751 for ; Fri, 4 Jul 2003 05:18:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64CIPZ2085750 for ietf-sasl-bks; Fri, 4 Jul 2003 05:18:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64CIOqt085745 for ; Fri, 4 Jul 2003 05:18:24 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (82-43-138-23.cable.ubr01.newm.blueyonder.co.uk [82.43.138.23]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h64CM1V13552; Fri, 4 Jul 2003 06:22:01 -0600 Message-ID: <3F057089.DE9855FB@isode.com> Date: Fri, 04 Jul 2003 06:18:17 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Siemborski CC: Greg Hudson , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: > On Thu, 3 Jul 2003, Alexey Melnikov wrote: > > > Ok people. I am afraid we are starting a religious war at this point and > > this is not going to do us any good. > > I agree. > > > So, how about making some constructive suggestions. How about the following: > > 1). libraries MUST NOT specify callbacks when calling > > sasl_client_init/sasl_server_init. > > Global callbacks are thus deprecated. > > > > 2). a new function is added to set getopt callback. An application that > > doesn't care about getopt, will not call this function. If this callback > > is not set, the SASL library will use reasonable defaults or get the > > required information from own config file/environment/registry/whatever. > > > > 3). one of the getopt options is a plugin directory. If the application doesn't > > care, its getopt callback will fail to return the value for this option. The > > SASL library will choose a reasonable default in this case. If the SASL library > > doesn't support plugins, it will not care about this option. > > This is worse than the global callbacks scenario with libraries forbidden > from setting global callbaks, since in this situation a libary can call > the magic new function to set the getopt() callback. IMHO, it is not different. You can't prevent libraries or applications from doing stupid things, you can only advise them how to avoid problems. > I don't see how this is better than allowing a getopt() callback to be set > by the application, but not by libraries in the call to sasl_xxx_init(). Would you rather allow getopt (and only getopt) to be set by the application when calling a sasl_xxx_init() and a library using SASL always pass NULL as callbacks? > Even if we forbid libraries from calling this new function, the situation > is worse than allowing applications to set a getopt callback in their call > to sasl_xxx_init(), as it requires changes from current practice. > > > I believe this is how it works now anyway (except for new function for setting > > getopt). > > Not quite true, this requires standardizing the name of an option, as > well. I meant in Cyrus SASL library, not the document. Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Fri Jul 4 05:39:03 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64Cd3qt086288 for ; Fri, 4 Jul 2003 05:39:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64Cd3j0086287 for ietf-sasl-bks; Fri, 4 Jul 2003 05:39:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64Cd2qt086282 for ; Fri, 4 Jul 2003 05:39:02 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (82-43-138-23.cable.ubr01.newm.blueyonder.co.uk [82.43.138.23]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h64CgfV13699; Fri, 4 Jul 2003 06:42:42 -0600 Message-ID: <3F057561.23539745@isode.com> Date: Fri, 04 Jul 2003 06:38:57 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg Hudson CC: ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> <1057272175.12524.444.camel@error-messages.mit.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greg Hudson wrote: > On Thu, 2003-07-03 at 18:27, Alexey Melnikov wrote: > > So, how about making some constructive suggestions. How about the following: > > 1). libraries MUST NOT specify callbacks when calling > > sasl_client_init/sasl_server_init. > > Global callbacks are thus deprecated. > > You seem to leave open the question of whether applications are allowed > to specify callbacks. Sorry, forgot about that. Either an application should pass NULL as a library (and new function is introduced for setting getopt as described), or the application is only allowed to set getopt as a global callback. In this case interaction between global callbacks and local one should be documented. > Was that intentional? No. > (As I've mentioned before, if applications are allowed to set global > callbacks, then a library using SASL cannot guard against accidentally > triggering the application global callbacks.) > > > 2). a new function is added to set getopt callback. An application that doesn't > > care about getopt, will not call this function. > > Well, as everybody knows, my religion does not include such a device, > but global state is generally not burdensome as long as it's > (completely) optional. So I won't scream and yell about it. I was hoping for this :-). Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Fri Jul 4 07:32:36 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64EWaqt090184 for ; Fri, 4 Jul 2003 07:32:36 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64EWatw090183 for ietf-sasl-bks; Fri, 4 Jul 2003 07:32:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64EWZqt090176 for ; Fri, 4 Jul 2003 07:32:35 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (82-43-138-23.cable.ubr01.newm.blueyonder.co.uk [82.43.138.23]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h64EaFV14473; Fri, 4 Jul 2003 08:36:15 -0600 Message-ID: <3F058FFF.E7D32D15@isode.com> Date: Fri, 04 Jul 2003 08:32:31 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Siemborski CC: Greg Hudson , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> <3F057089.DE9855FB@isode.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: > On Fri, 4 Jul 2003, Alexey Melnikov wrote: > > > > I don't see how this is better than allowing a getopt() callback to be set > > > by the application, but not by libraries in the call to sasl_xxx_init(). > > > > Would you rather allow getopt (and only getopt) to be set by the > > application when calling a sasl_xxx_init() and a library using SASL > > always pass NULL as callbacks? > > Yes, since it is much closer to what is currently done, and I don't see > the gain of adding a separate "set getopt" function which needs to be > called before sasl_xxx_init anyway. If there's a concrete gain that > justified the change in code, I'd be less opposed. > > > > Not quite true, this requires standardizing the name of an option, as > > > well. > > > > I meant in Cyrus SASL library, not the document. > > So option names would still be non-standard? Doesn't this not address > Greg's concern then? I think it should be standard, but Greg wouldn't care :-). Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Fri Jul 4 07:29:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64ETbqt089725 for ; Fri, 4 Jul 2003 07:29:37 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64ETb4t089724 for ietf-sasl-bks; Fri, 4 Jul 2003 07:29:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64ETVqt089704 for ; Fri, 4 Jul 2003 07:29:31 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h64ETVuO013505; Fri, 4 Jul 2003 10:29:31 -0400 Date: Fri, 4 Jul 2003 10:29:31 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: Greg Hudson , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library In-Reply-To: <3F057089.DE9855FB@isode.com> Message-ID: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> <3F057089.DE9855FB@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 4 Jul 2003, Alexey Melnikov wrote: > > I don't see how this is better than allowing a getopt() callback to be set > > by the application, but not by libraries in the call to sasl_xxx_init(). > > Would you rather allow getopt (and only getopt) to be set by the > application when calling a sasl_xxx_init() and a library using SASL > always pass NULL as callbacks? Yes, since it is much closer to what is currently done, and I don't see the gain of adding a separate "set getopt" function which needs to be called before sasl_xxx_init anyway. If there's a concrete gain that justified the change in code, I'd be less opposed. > > Not quite true, this requires standardizing the name of an option, as > > well. > > I meant in Cyrus SASL library, not the document. So option names would still be non-standard? Doesn't this not address Greg's concern then? -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 Fri Jul 4 07:46:16 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64EkGqt091563 for ; Fri, 4 Jul 2003 07:46:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64EkGCo091562 for ietf-sasl-bks; Fri, 4 Jul 2003 07:46:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64EkEqt091557 for ; Fri, 4 Jul 2003 07:46:15 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h64EkFIi009942; Fri, 4 Jul 2003 10:46:15 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h64Ek52e010251; Fri, 4 Jul 2003 10:46:05 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h64Ek4FJ027290; Fri, 4 Jul 2003 10:46:04 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h64Ek3Ai026695; Fri, 4 Jul 2003 10:46:03 -0400 Subject: Re: Using SASL C API from a library From: Greg Hudson To: Alexey Melnikov Cc: ietf-sasl@imc.org In-Reply-To: <3F057561.23539745@isode.com> References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> <1057272175.12524.444.camel@error-messages.mit.edu> <3F057561.23539745@isode.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057329958.12524.476.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 04 Jul 2003 10:46:03 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 2003-07-04 at 08:38, Alexey Melnikov wrote: > Sorry, forgot about that. Either an application should pass NULL as a library (and > new function is introduced for setting getopt as described), or the application is > only allowed to set getopt as a global callback. In this case interaction between > global callbacks and local one should be documented. It sounds like we get the simplest transition if we make the changes: * Libraries must pass NULL for the global callbacks. * Applications must pass NULL, or only a getopt callback. * Applications MAY pass a getopt callback, but we don't say they SHOULD. Existing SASL implementations don't have to do anything except modify their documentation. To resolve my other issue while still preserving the ability to use a non-standard thread library: * sasl_set_mutex() becomes optional, but must be called from the initial single-threaded environment if it is called at all. If it is not called, the library will use the most standard native thread APIs to protect any internal global state. * sasl_*_init() no longer needs to be called from the initial single-threaded environment. This change is more burdensome.for existing implementations which have internal global state to protect; they must use threads (I'm told the pthreads API works under Windows, but I don't know how advisable it is to use it) and introduce a link-time dependency on a threads library. But the API does then become safely usable from a library. (I am okay with allowing implementations to simply not advertise thread safety, in which case they don't need to implement their own locks.) These changes do not turn the API into a shining example of standard API design in my book, of course; they are merely proposed as a practical compromise. Rob Siemborski wrote: > So option names would still be non-standard? Doesn't this not address > Greg's concern then? There are my concerns about the API's practical usability from a library, and there are my concerns about good design of a standard API, and I haven't kept them separate in this discussion. The former concerns are mostly objective, but it's clear that the other members of this working group don't agree with me on the latter concerns, so I will try to stick to the former. With that proviso, having a pseudo-standardized getopt() is okay as long as we don't enforce its use by callers. So I have concerns with the following text in the current draft: The most important callback is the "getopt" callback (see section 3.3.3) which is used to retrieve security policy option set- tings from the caller's preferences. This text worries me because the getopt callback is referred to as "important" and because security policy should be retrieved through a fully standard interface. (That may require a lot of work; I haven't thought about that problem in great detail.) Imagine trying to build an application which has a GUI to configure security policy preferences using the current design. The callbacks argument is the default list of callbacks (see sec- tion 3.1.1 for definition of sasl_callback_t structure) and SHOULD include the sasl_getopt_t callback (see section 3.3.3). This text worries me because, again, it seems to expect that the implementation will really want to see a getopt callback and will behave only minimally usefully without one. From owner-ietf-sasl Fri Jul 4 08:16:03 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64FG2qt093945 for ; Fri, 4 Jul 2003 08:16:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64FG2IG093944 for ietf-sasl-bks; Fri, 4 Jul 2003 08:16:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64FG1qt093939 for ; Fri, 4 Jul 2003 08:16:01 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h64FG1uO014471; Fri, 4 Jul 2003 11:16:01 -0400 Date: Fri, 4 Jul 2003 11:16:00 -0400 (EDT) From: Rob Siemborski To: Greg Hudson cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library In-Reply-To: <1057329958.12524.476.camel@error-messages.mit.edu> Message-ID: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> <1057272175.12524.444.camel@error-messages.mit.edu> <3F057561.23539745@isode.com> <1057329958.12524.476.camel@error-messages.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 Fri, 4 Jul 2003, Greg Hudson wrote: > On Fri, 2003-07-04 at 08:38, Alexey Melnikov wrote: > > Sorry, forgot about that. Either an application should pass NULL as a library (and > > new function is introduced for setting getopt as described), or the application is > > only allowed to set getopt as a global callback. In this case interaction between > > global callbacks and local one should be documented. > > It sounds like we get the simplest transition if we make the changes: > > * Libraries must pass NULL for the global callbacks. > * Applications must pass NULL, or only a getopt callback. > * Applications MAY pass a getopt callback, but we don't say they > SHOULD. > > Existing SASL implementations don't have to do anything except modify > their documentation. I'm okay with this. > To resolve my other issue while still preserving the ability to use a > non-standard thread library: > > * sasl_set_mutex() becomes optional, but must be called from the > initial single-threaded environment if it is called at all. If > it is not called, the library will use the most standard native > thread APIs to protect any internal global state. > * sasl_*_init() no longer needs to be called from the initial > single-threaded environment. > > This change is more burdensome.for existing implementations which have > internal global state to protect; they must use threads (I'm told the > pthreads API works under Windows, but I don't know how advisable it is > to use it) and introduce a link-time dependency on a threads library. > But the API does then become safely usable from a library. > > (I am okay with allowing implementations to simply not advertise thread > safety, in which case they don't need to implement their own locks.) If this change allows for implementations to advertise thread safety only if sasl_set_mutex is called (from a non-threaded environment), I'm at least willing to talk about this. First, I think that calling sasl_set_mutex needs to be a "SHOULD" and not "OPTIONAL". I also worry a bit about sasl_xxx_init not being required to be called from a single non-threaded environment, since in order to simulate this the library would need to lock around it. If sasl_set_mutex has been called, presumably this means that sasl_set_mutex allocates the necessary mutex, but now we can never release this mutex safely (well, unless sasl_set_mutex was called again with all NULL values, I suppose). This may not be a practical concern. > These changes do not turn the API into a shining example of standard API > design in my book, of course; they are merely proposed as a practical > compromise. As you can probably understand, its really hard for me to not oppose significant changes in the API as we try to standardize it. We've already implemented two substantially different SASL APIs, I'm not looking forward to doing it a third time, especially given the deployment we currently have. Making it usable is one thing (for which I am willing to compromise), however making it a "shining example of API design" in ways that are not backwards compatible, just for the sake of doing so is probably going to see pushback. > The most important callback is the "getopt" callback (see > section 3.3.3) which is used to retrieve security policy option set- > tings from the caller's preferences. > > This text worries me because the getopt callback is referred to as > "important" and because security policy should be retrieved through a > fully standard interface. (That may require a lot of work; I haven't > thought about that problem in great detail.) Imagine trying to build an > application which has a GUI to configure security policy preferences > using the current design. I tend to agree that "security policy" decisions should be done through standard interfaces. Of course, if things like telling the mechanisms what database to pull user secrets from (or how to authenticate to that database, or so on) is a "security policy" decision, we're going to have problems defining any standard interface to deal with this. I think this sentence can just be eliminated, it doesn't really add anything useful to section 3.3.1. > The callbacks argument is the default list of callbacks (see sec- > tion 3.1.1 for definition of sasl_callback_t structure) and SHOULD > include the sasl_getopt_t callback (see section 3.3.3). > > This text worries me because, again, it seems to expect that the > implementation will really want to see a getopt callback and will behave > only minimally usefully without one. I'm willing to change SHOULD to a MAY here (for applications), and MUST NOT (for libraries). Something like: The callbacks argument is the default list of callbacks (see section 3.1.1 for definition of sasl_callback_t structure). Libraries that are clients of the API MUST supply NULL For this parameter. Applications that are clients of the API MAY supply a list that includes the sasl_getopt_t callback, but MUST NOT supply any other callbacks through this interface. -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 Fri Jul 4 08:27:31 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64FRVqt094204 for ; Fri, 4 Jul 2003 08:27:31 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64FRVG4094203 for ietf-sasl-bks; Fri, 4 Jul 2003 08:27:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64FRUqt094198 for ; Fri, 4 Jul 2003 08:27:30 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h64FRUIi016142; Fri, 4 Jul 2003 11:27:30 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h64FRPcd011263; Fri, 4 Jul 2003 11:27:30 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h64FRNU8009085; Fri, 4 Jul 2003 11:27:24 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h64FRK9e026733; Fri, 4 Jul 2003 11:27:20 -0400 Subject: Re: Using SASL C API from a library From: Greg Hudson To: Rob Siemborski Cc: ietf-sasl@imc.org In-Reply-To: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> <1057272175.12524.444.camel@error-messages.mit.edu> <3F057561.23539745@isode.com> <1057329958.12524.476.camel@error-messages.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057332439.12524.484.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 04 Jul 2003 11:27:20 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I understand not wanting to make incompatible changes to the API at this time. On Fri, 2003-07-04 at 11:16, Rob Siemborski wrote: > If this change allows for implementations to advertise thread safety only > if sasl_set_mutex is called (from a non-threaded environment), I'm at least > willing to talk about this. Well, as long as they're clear, they can hedge all they want, I suppose. > I also worry a bit about sasl_xxx_init not being required to be called > from a single non-threaded environment, since in order to simulate this > the library would need to lock around it. If sasl_set_mutex has been > called, presumably this means that sasl_set_mutex allocates the necessary > mutex, but now we can never release this mutex safely (well, unless > sasl_set_mutex was called again with all NULL values, I suppose). This > may not be a practical concern. pthreads allows you to create a statically intialized mutex. You'd never release such a beast; you'd just use it to lock around non-thread-safe operations. > The callbacks argument is the default list of callbacks (see section 3.1.1 > for definition of sasl_callback_t structure). Libraries that are clients > of the API MUST supply NULL For this parameter. Applications that are > clients of the API MAY supply a list that includes the sasl_getopt_t > callback, but MUST NOT supply any other callbacks through this interface. That looks okay to me. From owner-ietf-sasl Fri Jul 4 08:37:49 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64Fbnqt095264 for ; Fri, 4 Jul 2003 08:37:49 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64Fbn3a095263 for ietf-sasl-bks; Fri, 4 Jul 2003 08:37:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64Fblqt095256 for ; Fri, 4 Jul 2003 08:37:47 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp6.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h64Fblil005193; Fri, 4 Jul 2003 11:37:47 -0400 Date: Fri, 4 Jul 2003 11:37:47 -0400 (EDT) From: Rob Siemborski To: Greg Hudson cc: ietf-sasl@imc.org Subject: Re: Using SASL C API from a library In-Reply-To: <1057332439.12524.484.camel@error-messages.mit.edu> Message-ID: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> <1057272175.12524.444.camel@error-messages.mit.edu> <3F057561.23539745@isode.com> <1057329958.12524.476.camel@error-messages.mit.edu> <1057332439.12524.484.camel@error-messages.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 Fri, 4 Jul 2003, Greg Hudson wrote: > > I also worry a bit about sasl_xxx_init not being required to be called > > from a single non-threaded environment, since in order to simulate this > > the library would need to lock around it. If sasl_set_mutex has been > > called, presumably this means that sasl_set_mutex allocates the necessary > > mutex, but now we can never release this mutex safely (well, unless > > sasl_set_mutex was called again with all NULL values, I suppose). This > > may not be a practical concern. > > pthreads allows you to create a statically intialized mutex. You'd > never release such a beast; you'd just use it to lock around > non-thread-safe operations. That's true. However, if sasl_set_mutex *is* called we have no way of staticly allocating a mutex, since we have to dynamicly call the init function to get the proper mutex (and we may not be using pthread mutexes). -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 Fri Jul 4 08:47:00 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64Fl0qt096345 for ; Fri, 4 Jul 2003 08:47:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64Fl0r0096344 for ietf-sasl-bks; Fri, 4 Jul 2003 08:47:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64Fkxqt096337 for ; Fri, 4 Jul 2003 08:46:59 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h64Fkwc6086291; Fri, 4 Jul 2003 15:46:58 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030704084120.01c76430@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 04 Jul 2003 08:43:53 -0700 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-anon-02.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200307022034.QAA13327@ietf.org> <200307022034.QAA13327@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 11:35 AM 7/3/2003, Rob Siemborski wrote: >On Wed, 2 Jul 2003 Internet-Drafts@ietf.org wrote: > > >> Title : The Anonymous SASL Mechanism >> Author(s) : K. Zeilenga >> Filename : draft-ietf-sasl-anon-02.txt > >>> >...not part of SASL itself. Newer profiles of SASL will include the >client message with the AUTHENTICATE command itself so the extra round >trip below (the server response with an empty "+ ") can be eliminated. ><< > >Seems to indicate a requirement on new SASL profiles, which is outside of >the scope of the document. However, it is reasonable to add some >clarification that the extra round trip is an artifact of the IMAP >profile. > >How about something more like: > >...not part of SASL itself. Additionally, protocols with SASL profiles >permitting an initial client response will be able to avoid the extra >round trip below (the server response with an empty "+ "). This sounds like a reasonable suggestion... Kurt From owner-ietf-sasl Sat Jul 5 21:52:47 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h664qWqt013065 for ; Sat, 5 Jul 2003 21:52:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h664qWAX013064 for ietf-sasl-bks; Sat, 5 Jul 2003 21:52:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-TWO-SIXTY-TWO.MIT.EDU [18.187.6.7]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h664pAqt013041 for ; Sat, 5 Jul 2003 21:51:10 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 7A798151D96; Sun, 6 Jul 2003 00:51:02 -0400 (EDT) To: Alexey Melnikov Cc: Greg Hudson , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> From: Sam Hartman Date: Sun, 06 Jul 2003 00:51:02 -0400 In-Reply-To: <3F04ADD2.31E16D8B@isode.com> (Alexey Melnikov's message of "Thu, 03 Jul 2003 16:27:30 -0600") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> Ok people. I am afraid we are starting a religious war at Alexey> this point and this is not going to do us any good. If this were a WG item I'd disagree that anyone was proposing a religious war. I'd comment that there seems to be an unspecified requirement behind the global getopt callback. I'd ask the proponents of that callback to describe clearly what problem it was trying to solve. Then, I'd see if the WG could reach consensus on whether that problem was a good thing to solve in a standards track API. If the WG reached consensus on a problem and agreed the problem was worth solving, then we would look at whether the getopt callback actually solved that problem. But this document is not a WG item; you can use whatever procedure you like to decide its contents. From owner-ietf-sasl Mon Jul 7 10:23:33 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67HNXqt079048 for ; Mon, 7 Jul 2003 10:23:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h67HNX3s079047 for ietf-sasl-bks; Mon, 7 Jul 2003 10:23:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (HOTASS-3.MIT.EDU [18.101.1.43]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67HNWqt079042 for ; Mon, 7 Jul 2003 10:23:32 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 6443915201D; Mon, 7 Jul 2003 13:23:33 -0400 (EDT) To: ietf-sasl@imc.org Subject: Proposed Agenda From: Sam Hartman Date: Mon, 07 Jul 2003 13:23:33 -0400 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: People should speak up today if there are other issues that need to be covered. 1) preliminary stuff - 5m 2) 2222bis - 15m 3) saslprep - 15m 4) other issues - 15m 5) open mic - remainder From owner-ietf-sasl Thu Jul 10 14:55:05 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6ALt5qt019518 for ; Thu, 10 Jul 2003 14:55:05 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6ALt5KP019517 for ietf-sasl-bks; Thu, 10 Jul 2003 14:55:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6ALswqt019503 for ; Thu, 10 Jul 2003 14:55:04 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust29.tnt101.lnd4.gbr.da.uu.net [213.116.50.29]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h6ALwSV18970; Thu, 10 Jul 2003 15:58:30 -0600 Message-ID: <3F0DD586.77AD0B39@isode.com> Date: Thu, 10 Jul 2003 15:07:18 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Proposed Agenda References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: > People should speak up today if there are other issues that need to be covered. > > 1) preliminary stuff - 5m > 2) 2222bis - 15m > 3) saslprep - 15m > 4) other issues - 15m > 5) open mic - remainder There is a 50% chance that I will not be in Vienna (and there is some probability that even if I will be, I might miss the SASL meeting). Any takers to serve as proxy for me (i.e. 2222bis document and DIGEST-MD5)? Can we also have a virtual "show of hands" for people who are planning to attend? Please send replies to me and I will post the list to the mailing list. I am not sure what is included in "other issues", but some potential topics for discussion: 1). SASL C API (out of scope, but a lot of discussion lately) 2). Status of GSSAPI draft now that the base32 document is an RFC? Also, I've asked Application Area ADs for a slot to talk about HTTP SASL during Application Area Open Meeting on Monday. Assuming there is time, Peter Yee from RSA will present if I am not present. Cheers, Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ From owner-ietf-sasl Fri Jul 11 19:24:35 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6C2OZqt035790 for ; Fri, 11 Jul 2003 19:24:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6C2OZm8035789 for ietf-sasl-bks; Fri, 11 Jul 2003 19:24:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smith.dodgethis.org (postfix@netblock-66-159-211-115.dslextreme.com [66.159.211.115]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6C2OXqt035784 for ; Fri, 11 Jul 2003 19:24:33 -0700 (PDT) (envelope-from wpc4@dodgethis.org) Received: from dejour (dejour.dodgethis.org [192.168.0.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smith.dodgethis.org (Postfix) with ESMTP id 22ABA37ACC for ; Fri, 11 Jul 2003 19:24:34 -0700 (PDT) Message-ID: <000a01c3481c$c96eecc0$0600a8c0@dejour> From: "William Curley" To: Subject: SASL w/auxprop(mysql) and shadow {Scanned} Date: Fri, 11 Jul 2003 19:24:56 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C347E2.1C5D6690" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C347E2.1C5D6690 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am trying to allow Postfix to authenticate via SASL to send email, = SASL will either use the local shadow file or a mysql database to do the = authentication. I currently have this setup more or less using = 'saslauthd -a pam' and mysql-pam. I'd really like to just use SASL since = it appears to support this. I understand that auxprop can connect to a = mysql database, how do I start auxprop so it can do this? Or do I need = to do this? With both pwcheck and saslauthd I've had to have the daemons = running for it to work. Lastly, is it even possible to have SASL try to = authenticate to both shadow and mysql at the same time? Thanks kindly = for any light you can shed on this. William Curley wpc4@dodgethis.org http://www.dodgethis.org - Free email and more. ------=_NextPart_000_0007_01C347E2.1C5D6690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am trying to allow Postfix to = authenticate via=20 SASL to send email, SASL will either use the local shadow file or a = mysql=20 database to do the authentication. I currently have this setup more or = less=20 using 'saslauthd -a pam' and mysql-pam. I'd really like to just use SASL = since=20 it appears to support this. I understand that auxprop can connect to a = mysql=20 database, how do I start auxprop so it can do this? Or do I need to do = this?=20 With both pwcheck and saslauthd I've had to have the daemons running for = it to=20 work. Lastly, is it even possible to have SASL try to authenticate to = both=20 shadow and mysql at the same time? Thanks kindly for any light you can = shed on=20 this.
 
 
William Curley
wpc4@dodgethis.org
http://www.dodgethis.org - Free = email and=20 more.
------=_NextPart_000_0007_01C347E2.1C5D6690-- From owner-ietf-sasl Sat Jul 12 03:35:36 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6CAZaqt076201 for ; Sat, 12 Jul 2003 03:35:36 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6CAZa48076200 for ietf-sasl-bks; Sat, 12 Jul 2003 03:35:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6CAZVqt076194 for ; Sat, 12 Jul 2003 03:35:35 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust97.tnt102.lnd4.gbr.da.uu.net [213.116.52.97]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h6CAdAV03350; Sat, 12 Jul 2003 04:39:10 -0600 Message-ID: <3F0F3D08.F71EEEEF@isode.com> Date: Fri, 11 Jul 2003 16:41:12 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: Proposed Agenda References: <3F0DD586.77AD0B39@isode.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Can we also have a virtual "show of hands" for people who are planning to attend? > Please send replies to me and I will post the list to the mailing list. So far I've received only two replies from Sam Hartman and Keith Burdis. Kurt Zeilenga should be also in Vienna. Alexey From owner-ietf-sasl Mon Jul 14 00:06:56 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6E76uqt034338 for ; Mon, 14 Jul 2003 00:06:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6E76ssb034332 for ietf-sasl-bks; Mon, 14 Jul 2003 00:06:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6E76oqt034320 for ; Mon, 14 Jul 2003 00:06:53 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h6E76hc6080394; Mon, 14 Jul 2003 07:06:44 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030714035247.01cda048@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 14 Jul 2003 03:56:41 +0200 To: "William Curley" From: "Kurt D. Zeilenga" Subject: Re: SASL w/auxprop(mysql) and shadow {Scanned} Cc: In-Reply-To: <000a01c3481c$c96eecc0$0600a8c0@dejour> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As this list is for discussion regarding current and future SASL standardization efforts and, in particular, the work of the IETF SASL working group, your post is off topic. I suggest you direct your post to a list concerning CMU's Cyrus SASL implementation, e.g., . Kurt, IETF SASL WG co-chair At 04:24 AM 7/12/2003, William Curley wrote: >I am trying to allow Postfix to authenticate via SASL to send email, SASL will either use the local shadow file or a mysql database to do the authentication. I currently have this setup more or less using 'saslauthd -a pam' and mysql-pam. I'd really like to just use SASL since it appears to support this. I understand that auxprop can connect to a mysql database, how do I start auxprop so it can do this? Or do I need to do this? With both pwcheck and saslauthd I've had to have the daemons running for it to work. Lastly, is it even possible to have SASL try to authenticate to both shadow and mysql at the same time? Thanks kindly for any light you can shed on this. > > >William Curley >wpc4@dodgethis.org >http://www.dodgethis.org - Free email and more. From owner-ietf-sasl Tue Jul 15 08:25:21 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FFPLqt084338 for ; Tue, 15 Jul 2003 08:25:21 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6FFPLtb084337 for ietf-sasl-bks; Tue, 15 Jul 2003 08:25:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FFPKqt084331 for ; Tue, 15 Jul 2003 08:25:20 -0700 (PDT) (envelope-from jeffrey.t.moore@sun.com) Received: from jurassic.eng.sun.com ([129.146.17.55]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6FFPLRi004171 for ; Tue, 15 Jul 2003 09:25:21 -0600 (MDT) Received: from sun.com (vpn-129-150-19-113.SFBay.Sun.COM [129.150.19.113]) by jurassic.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h6FFPKte268007 for ; Tue, 15 Jul 2003 08:25:20 -0700 (PDT) Message-ID: <3F141CD8.AC475D3C@sun.com> Date: Tue, 15 Jul 2003 08:25:12 -0700 From: Jeff Moore X-Mailer: Mozilla 4.79 (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "ietf-sasl@imc.org" Subject: Global state and libsasl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As has been previously discussed, libsasl maintains global state which can cause problems when both an application and one of its libraries use libsasl. The most recent suggestions on how to deal with this issue in a compatible way do not seem to address all the issues with global state in the Cyrus libsasl implementation. The Cyrus 2.x libsasl implementation uses global state for the following: 1. Loading plugins If an application decides which plugins to load and how to configure them, any other consumers of libsasl may not not have their needs met. Additionally, some plugins may be specific to a given application or library. They may not want the plugin to be used by other components. There are a number of ways there could be problems: a. Location of plugins (SASL_CB_GETPATH) Through the SASL_CB_GETPATH callback. If this callback is specified, libsasl will use the specified path to locate plugins. The specified path may not include the standard plugins - or it may include "private" plugins. b. Verification of plugins/configuration (SASL_CB_VERIFYFILE) Through the SASL_CB_VERIFYFILE callback. What one component may accept another might reject. c. logging of non-connection oriented problems (SASL_CB_LOG) libraries will not be able to report these sorts of problems themselves. d. Setting any global plugin configuration data: e.g. DIGEST-MD5 - reauth_timeout, GSSAPI - keytab KERBEROS_4 - srvtab SRP - srp_mda The way to set these today is via the getopt function registered in the global callback. Also note that for things like reauth_timeout, you may not want to share it between different components. e. Loading application/library specific plugins Any plugin that is loaded via sasl_xxx_add_plugin will be available to application or libraries. f. Loading application/library private plugins 2. memory allocation sasl_set_alloc() setting memory allocation functions may have unintended interactions between application and libraries. If the library has already used libsasl to perform some memory allocations before the application has set sasl_set_alloc(), bad things may happen. 3. mutex functions sasl_set_mutex() setting mutex allocation functions may have unintended interactions between applications and libraries. If this function is a MUST, what should a library do? 4. sasl_xxx_init() and sasl_done() Count of usage may deal with this - although no separation between client and server and potential for misbehaving applications/libraries to break others. 5. Global callbacks If specified, they will apply to both application and libraries. The application's global callbacks may end up handling callbacks for the library. If, as has been proposed, that libraries should not use global callbacks, the application will not see this problem. 6. Server sasl option configuration file Just as with global callbacks, options may be set for library that are not expected or wanted. 7. Requirement of non-thread-safe initialization. Ideally, we would all like to see the global state problem be solved with a minimum of changes to the existing semantics. One way to address much of the above is to introduce a sasl global context that would be inferred by the current sasl API, but which would allow libraries (or applications) to use libsasl independently of each other. (There are additional issues for sasl_set_alloc() and sasl_set_mutex().) This approach would introduce a number of new functions: void *sasl_create_context(void) Create a sasl global context - the current global state would be now associated with the created context. void sasl_free_context(void *ctx) Release all resources associated with the sasl global context. This would be semantically the same as the current sasl_done(). int _sasl_client_init(void *ctx, const sasl_callback_t *callbacks); Initialize the sasl global context for sasl client access. int _sasl_client_new(void *ctx, const char *service, ...) Create a sasl client connection using the sasl global context. int _sasl_server_init(void *ctx, const sasl_callback_t *callbacks, ...); Initialize the sasl global context for sasl server access. int _sasl_server_new(void *ctx, const char *service, ...) Create a sasl server connection using the sasl global context. int _sasl_client_add_plugin(void *ctx, const char *plugname, ...); int _sasl_server_add_plugin(void *ctx, const char *plugname, ...); int _sasl_canonuser_add_plugin(void *ctx, const char *plugname, ...); int _sasl_auxprop_add_plugin(void *ctx, const char *plugname, ...); Add plugins to the sasl global context The functions sasl_set_mutex() and sasl_global_listmech() would be deprecated. If sasl_set_alloc() is not deprecated, then _sasl_set_alloc(void *ctx, ...) could be defined. This approach would preserve the existing semantic and avoid: global state issues when a library initializes the libsasl before the application, the potential problem of applications getting callbacks for libraries and plugins installed by one component being available for use by other components. Cheers, Jeff From owner-ietf-sasl Tue Jul 15 09:22:02 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FGM2qt086896 for ; Tue, 15 Jul 2003 09:22:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6FGM2Re086895 for ietf-sasl-bks; Tue, 15 Jul 2003 09:22:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FGM1qt086890 for ; Tue, 15 Jul 2003 09:22:01 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h6FGM2g4018998; Tue, 15 Jul 2003 12:22:02 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h6FGM2jH007752; Tue, 15 Jul 2003 12:22:02 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h6FGM1U8009513; Tue, 15 Jul 2003 12:22:01 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h6FGM0YH015609; Tue, 15 Jul 2003 12:22:00 -0400 Subject: Re: Global state and libsasl From: Greg Hudson To: Jeff Moore Cc: "ietf-sasl@imc.org" In-Reply-To: <3F141CD8.AC475D3C@sun.com> References: <3F141CD8.AC475D3C@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1058286116.13068.69.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 15 Jul 2003 12:22:00 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2003-07-15 at 11:25, Jeff Moore wrote: > int _sasl_client_init(void *ctx, const sasl_callback_t *callbacks); What's with the leading underscores? Symbols like that are reserved for external linkage by the ANSI C standard. From owner-ietf-sasl Wed Jul 16 01:06:33 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6G86Xqt046115 for ; Wed, 16 Jul 2003 01:06:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6G86XDF046114 for ietf-sasl-bks; Wed, 16 Jul 2003 01:06:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu ([81.160.157.184]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6G86Wqt046108 for ; Wed, 16 Jul 2003 01:06:32 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id ED6AD151D60; Wed, 16 Jul 2003 04:06:23 -0400 (EDT) To: housley@vigilsec.com, smb@research.att.com Cc: ietf-sasl@imc.org Subject: Summary of the SASL working group meeting From: Sam Hartman Date: Wed, 16 Jul 2003 04:06:23 -0400 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: The SASL working group met on Tuesday for one hour. The document editor of RFC 2222bis (Alexei) will publish a revision in the first week of August at which point we will last call it. The saslprep document is to be revised to include informational mapping tables but is otherwise ready for last call. New revision is expected shortly after the meeting and the last call will follow shortly after it is announced. Working group participants who made comments during the plain or anonymous last call need to make sure their comments are reflected in the current document. The document editor believes that the working group is done with these two documents although we are not sending them to the IESG at this time. The working group decided that AES for digest-md5 will use random IVs rather than counter mode. Counter mode is harder to implement correctly. There is likely to be interest in making the RC4 cipher mandatory-to-implement for implementations that support confidentiality with digest-md5. The RC4 cipher is interoperable with existing implementations and we did not find any problems during the security review conducted after the last meeting. Currently, neither integrity protection nor confidentiality is mandatory-to-implement. At least one participant said he would remove digest-md5 support rather than implement integrity. The argument is that you can just use TLS. However, if you just use TLS, you need to depend on TLS to authenticate the server to the client or you have a man-in-the-mdille problem. This will be discussed on the list. The working group reached a consensus at the meeting to deprecate DES and 3DES because they are insecure. Larry submitted a 00 version of the GSSAPI draft, but it did not appear. He will resubmit in the near future. Keith Burdis agreed to submit an SASL applicability statement as an individual submission. His document will include comparisons of the various sasl mechanisms and their security properties. Sam agreed to propose an outline for the document. The working group will discuss rechartering to include this document after the first revision. From owner-ietf-sasl Wed Jul 16 06:34:31 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GDYVqt082636 for ; Wed, 16 Jul 2003 06:34:31 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6GDYVsT082635 for ietf-sasl-bks; Wed, 16 Jul 2003 06:34:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GDYTqt082630 for ; Wed, 16 Jul 2003 06:34:29 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h6GDYPGv030702 for ; Wed, 16 Jul 2003 09:34:25 -0400 (EDT) Message-ID: <3F1554B6.9090601@oceana.com> Date: Wed, 16 Jul 2003 09:35:50 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: SASL mailing list Subject: Re: Summary of the SASL working group meeting References: In-Reply-To: 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: > Keith Burdis agreed to submit an SASL applicability statement as an > individual submission. His document will include comparisons of the > various sasl mechanisms and their security properties. Sam agreed to > propose an outline for the document. The working group will discuss > rechartering to include this document after the first revision. How will this document differ from the following? http://www.ietf.org/internet-drafts/draft-iab-auth-mech-00.txt -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Wed Jul 16 08:21:36 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GFLZqt086322 for ; Wed, 16 Jul 2003 08:21:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6GFLZVn086321 for ietf-sasl-bks; Wed, 16 Jul 2003 08:21:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu ([81.160.157.184]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GFLYqt086294 for ; Wed, 16 Jul 2003 08:21:34 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 21B06151D76; Wed, 16 Jul 2003 11:21:27 -0400 (EDT) To: Ken Murchison Cc: SASL mailing list Subject: Re: Summary of the SASL working group meeting References: <3F1554B6.9090601@oceana.com> From: Sam Hartman Date: Wed, 16 Jul 2003 11:21:27 -0400 In-Reply-To: <3F1554B6.9090601@oceana.com> (Ken Murchison's message of "Wed, 16 Jul 2003 09:35:50 -0400") 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: >>>>> "Ken" == Ken Murchison writes: Ken> Sam Hartman wrote: >> Keith Burdis agreed to submit an SASL applicability statement >> as an individual submission. His document will include >> comparisons of the various sasl mechanisms and their security >> properties. Sam agreed to propose an outline for the document. >> The working group will discuss rechartering to include this >> document after the first revision. Ken> How will this document differ from the following? Ken> http://www.ietf.org/internet-drafts/draft-iab-auth-mech-00.txt The IAB document seems to discuss mechanisms at a much lower level. I was invisioning comparing SASL to similar technologies like EAP, GSSAPI and TLS. And I was hoping to discuss sasl mechansims as sasl mechanisms. We should definitely point to the IAB document and when discussing mechanisms describe them in the category they fit into that framework. From owner-ietf-sasl Fri Jul 18 09:32:07 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IGW6qt007102 for ; Fri, 18 Jul 2003 09:32:06 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6IGW6Yr007101 for ietf-sasl-bks; Fri, 18 Jul 2003 09:32:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IGW2qt007092 for ; Fri, 18 Jul 2003 09:32:03 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h6IGVmGv003090; Fri, 18 Jul 2003 12:31:48 -0400 (EDT) Message-ID: <3F18214A.2030706@oceana.com> Date: Fri, 18 Jul 2003 12:33:14 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Keith Burdis , "Raif S. Naffah" CC: SASL mailing list Subject: draft-burdis-cat-srp-sasl-08 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: Trying to bring Cyrus SASL in to compliance with the latest draft. Here are some notes I put together after a thorough read of the auth exchange. I may have more when I get into integrity and security. Section 3.8: > When such entities travel on the wire, they shall be encoded as > 4-octet Scalar Numbers. We shall use the syntax uint(n) to denote > the encoding of an Unsigned Integer n. In what byte-order? I assume big-endian. Section 4.5: > The server computes its evidence M2, which proves to the client that > it knows the shared context key K, as well as U, I and o, as follows: ^^^ > > H( bytes(A) > | bytes(M1) > | bytes(K) Was U removed from the calculation on purpose, or was it an oversight? If its no longer part of the calculation, then it should be removed from the sentence describing M2. > | bytes(H( bytes(I) )) > | bytes(H( bytes(o) )) > | bytes(sid) If sid is UTF8, should it be hashed, like I and o? > | ttl Shouldn't this be bytes(ttl)? > ) > > All parameters received from the client that are used as input to a > digest operation MUST be used as received. > > The server sends: > > { os(M2) | os(sIV) | sid | ttl } ^^^^^^^^^^ Shouldn't this be utf8(sid) and uint(ttl)? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Tue Jul 22 14:54:44 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MLsiqt073585 for ; Tue, 22 Jul 2003 14:54:44 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6MLsiWd073584 for ietf-sasl-bks; Tue, 22 Jul 2003 14:54:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MLshqt073569 for ; Tue, 22 Jul 2003 14:54:43 -0700 (PDT) (envelope-from william.fiveash@sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6MLseDZ020776 for ; Tue, 22 Jul 2003 14:54:40 -0700 (PDT) Received: from alton.central.sun.com (alton.Central.Sun.COM [129.153.128.101]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6MLsdcm022888; Tue, 22 Jul 2003 15:54:39 -0600 (MDT) Received: from alton.central.sun.com (localhost [127.0.0.1]) by alton.central.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6MLsdkY463134; Tue, 22 Jul 2003 16:54:39 -0500 (CDT) Received: (from willf@localhost) by alton.central.sun.com (8.12.9+Sun/8.12.9/Submit) id h6MLsdXB463133; Tue, 22 Jul 2003 16:54:39 -0500 (CDT) X-Authentication-Warning: alton.central.sun.com: willf set sender to william.fiveash@sun.com using -f Date: Tue, 22 Jul 2003 16:54:39 -0500 From: Will Fiveash To: ietf-sasl@imc.org Cc: Jeff Moore Subject: Fwd: [Nicolas.Williams@sun.com: draft-ietf-cat-sasl-gssapi-XX.txt && error tokens] Message-ID: <20030722215438.GI456254@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Since Nico isn't subscribed I'm forwarding this for him. -- Will Fiveash Sun Microsystems Inc. Austin, TX, USA (TZ=CST6CDT) ----- Forwarded message from Nicolas Williams ----- Date: Tue, 22 Jul 2003 13:28:16 -0700 From: Nicolas Williams To: ietf-sasl@imc.org Subject: draft-ietf-cat-sasl-gssapi-XX.txt && error tokens User-Agent: Mutt/1.4i The last version of draft-ietf-cat-sasl-gssapi that I saw (-05) did not appropriately deal with GSS-API error tokens. Yes, there is such a thing as GSS-API error tokens, that is, GSS_Accept_sec_context() (and init too) can return a major status other than GSS_S_COMPLETE/GSS_S_CONTINUE_NEEDED *and* output a token at the same time. Such tokens SHOULD be sent. Sending GSS-API error tokens makes debugging errors a lot easier and results in error strings that make sense being displayed to the user. Also note: minor status codes are generally not standardized (certainly not for the Kerberos V GSS mechanism) and so minor error codes should not be sent on the wire as the peer may not be able to interpret them correctly (this is definitely the case with the Kerberos mech). Since I cannot find a current version of draft-ietf-cat-sasl-gssapi I will refrain from proposing actual text changes for now. Cheers, Nico -- ----- End forwarded message ----- From owner-ietf-sasl Tue Jul 22 16:25:32 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MNPJqt079502 for ; Tue, 22 Jul 2003 16:25:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6MNPJim079501 for ietf-sasl-bks; Tue, 22 Jul 2003 16:25:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MNO1qt079476 for ; Tue, 22 Jul 2003 16:24:01 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6MNNpxk014025; Tue, 22 Jul 2003 16:23:51 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6MNNocm023415; Tue, 22 Jul 2003 17:23:50 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h6MNKaQx010075; Tue, 22 Jul 2003 16:20:36 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6MNKZWk010074; Tue, 22 Jul 2003 18:20:35 -0500 (CDT) Date: Tue, 22 Jul 2003 18:20:35 -0500 From: Nicolas Williams To: ietf-sasl@imc.org, Keith Burdis , "Raif S. Naffah" Cc: Sam Hartman Subject: Comments on draft-burdis-cat-srp-sasl-08.txt Message-ID: <20030722232035.GD8918@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The following comments all pertain to the GSS-API mechanism defined in section 8 of draft-burdis-cat-srp-sasl-08.txt except where otherwise noted: 1. Mutual Authentication & SRP GSS Principal Naming The I-D claims to provide mutual authentication, but does not provide for naming acceptors. While I appreciate that SRP provides mutual authentication, unless one can bind the SRP password and verifier to an acceptor name then the acceptor name MUST be of type GSS_C_NT_ANONYMOUS. Sam Hartman has proposed appending, prepending or otherwise stirring the acceptor name into the password as a way to achieve mutual authentication with non-anonymous acceptors. The I-D should explain the limitations of its mutual authentication provision and/or add acceptor naming to the protocol. (See questions below.) Initiator naming should also be discussed. Additional questions: Should services be able to use this mechanism as initiators? How about optionally running the SRP protocol in both directions so that the initiator and acceptor can mutually authenticate without having to stir GSS-API names into the password/verifier? The two exchanges would have to be mutually bound, sure, perhaps in the last message of the double exchange. (In this case the verifiers could even be published, as long as they are distributed in a secure fashion.) 2. Channel Bindings I imagine that the I-D authors may have thought that GSS channel bindings are an esoteric, barely used feature of the GSS-API. A few months ago they have been correct. This is about to change; the use of GSS-API channel bindings is being formalized and given new life, see: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt If the protocol can be extended to accommodate integrity protected channel bindings I highly encourage you to do so. You can always define the encoding of the channel bindings by reference to RFC1964, module choice of hash function (this is how we're defining them for SPKM in draft-ietf-nfsv4-ccm-01.txt). 3. No Error Token Is Specified The GSS-API does, apparent widely spread assumptions notwithstanding, support the use of error tokens - i.e., output tokens emitted by gss_init_sec_context() or gss_accept_sec_context() when they also return a major status code other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED. This problem is significant. Please fix. 4. Obsoleted RFCs Do Not Make for Good Normative References This I-D references RFC2078 instead of RFC2743. Please fix. :) Cheers, Nico -- From owner-ietf-sasl Tue Jul 22 17:28:25 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6N0SOqt080945 for ; Tue, 22 Jul 2003 17:28:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6N0SOtg080944 for ietf-sasl-bks; Tue, 22 Jul 2003 17:28:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6N0SNqt080939 for ; Tue, 22 Jul 2003 17:28:23 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6N0SQEJ002193 for ; Tue, 22 Jul 2003 18:28:26 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6N0SPbO015631 for ; Tue, 22 Jul 2003 18:28:25 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h6N0PCQx010126 for ; Tue, 22 Jul 2003 17:25:12 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6N0PBJ9010125 for ietf-sasl@imc.org; Tue, 22 Jul 2003 19:25:11 -0500 (CDT) Date: Tue, 22 Jul 2003 18:20:35 -0500 From: Nicolas Williams To: ietf-sasl@imc.org, Keith Burdis , "Raif S. Naffah" Cc: Sam Hartman Subject: Comments on draft-burdis-cat-srp-sasl-08.txt Message-ID: <20030722232035.GD8918@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The following comments all pertain to the GSS-API mechanism defined in section 8 of draft-burdis-cat-srp-sasl-08.txt except where otherwise noted: 1. Mutual Authentication & SRP GSS Principal Naming The I-D claims to provide mutual authentication, but does not provide for naming acceptors. While I appreciate that SRP provides mutual authentication, unless one can bind the SRP password and verifier to an acceptor name then the acceptor name MUST be of type GSS_C_NT_ANONYMOUS. Sam Hartman has proposed appending, prepending or otherwise stirring the acceptor name into the password as a way to achieve mutual authentication with non-anonymous acceptors. The I-D should explain the limitations of its mutual authentication provision and/or add acceptor naming to the protocol. (See questions below.) Initiator naming should also be discussed. Additional questions: Should services be able to use this mechanism as initiators? How about optionally running the SRP protocol in both directions so that the initiator and acceptor can mutually authenticate without having to stir GSS-API names into the password/verifier? The two exchanges would have to be mutually bound, sure, perhaps in the last message of the double exchange. (In this case the verifiers could even be published, as long as they are distributed in a secure fashion.) 2. Channel Bindings I imagine that the I-D authors may have thought that GSS channel bindings are an esoteric, barely used feature of the GSS-API. A few months ago they have been correct. This is about to change; the use of GSS-API channel bindings is being formalized and given new life, see: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt If the protocol can be extended to accommodate integrity protected channel bindings I highly encourage you to do so. You can always define the encoding of the channel bindings by reference to RFC1964, module choice of hash function (this is how we're defining them for SPKM in draft-ietf-nfsv4-ccm-01.txt). 3. No Error Token Is Specified The GSS-API does, apparent widely spread assumptions notwithstanding, support the use of error tokens - i.e., output tokens emitted by gss_init_sec_context() or gss_accept_sec_context() when they also return a major status code other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED. This problem is significant. Please fix. 4. Obsoleted RFCs Do Not Make for Good Normative References This I-D references RFC2078 instead of RFC2743. Please fix. :) Cheers, Nico -- From owner-ietf-sasl Tue Jul 22 21:12:09 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6N4C9qt087807 for ; Tue, 22 Jul 2003 21:12:09 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6N4C9cT087806 for ietf-sasl-bks; Tue, 22 Jul 2003 21:12:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6N4C8qt087801 for ; Tue, 22 Jul 2003 21:12:08 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h6N4C8c6078307 for ; Wed, 23 Jul 2003 04:12:10 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030723060828.01b9cab8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 23 Jul 2003 06:08:52 +0200 To: ietf-sasl@imc.org From: Nicolas Williams Subject: draft-ietf-cat-sasl-gssapi-XX.txt && error tokens Mime-Version: 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 last version of draft-ietf-cat-sasl-gssapi that I saw (-05) did not appropriately deal with GSS-API error tokens. Yes, there is such a thing as GSS-API error tokens, that is, GSS_Accept_sec_context() (and init too) can return a major status other than GSS_S_COMPLETE/GSS_S_CONTINUE_NEEDED *and* output a token at the same time. Such tokens SHOULD be sent. Sending GSS-API error tokens makes debugging errors a lot easier and results in error strings that make sense being displayed to the user. Also note: minor status codes are generally not standardized (certainly not for the Kerberos V GSS mechanism) and so minor error codes should not be sent on the wire as the peer may not be able to interpret them correctly (this is definitely the case with the Kerberos mech). Since I cannot find a current version of draft-ietf-cat-sasl-gssapi I will refrain from proposing actual text changes for now. Cheers, Nico -- From owner-ietf-sasl Wed Jul 23 06:32:47 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NDWlqt041677 for ; Wed, 23 Jul 2003 06:32:47 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NDWlVa041676 for ietf-sasl-bks; Wed, 23 Jul 2003 06:32:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NDWjqt041663 for ; Wed, 23 Jul 2003 06:32:46 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id 76E2A76614; Wed, 23 Jul 2003 09:33:39 -0400 (EDT) To: Nicolas Williams Cc: ietf-sasl@imc.org, Keith Burdis , "Raif S. Naffah" Subject: Re: Comments on draft-burdis-cat-srp-sasl-08.txt References: <20030722232035.GD8918@binky.central.sun.com> From: Sam Hartman Date: Wed, 23 Jul 2003 09:33:39 -0400 In-Reply-To: <20030722232035.GD8918@binky.central.sun.com> (Nicolas Williams's message of "Tue, 22 Jul 2003 18:20:35 -0500") Message-ID: <87smox5pvw.fsf@luminous.mit.edu> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: To clarify, I don't believe that Nico's comments about mutual authentication actually are specific to the GSSAPI mechanism. The SRP SASL mechanism seems to only provide mutual authentication if the same password and verifier is used only on one server. I'm not sure how appropriate this is for a SASL mechanism; it seems like you will have difficulty distinguishing between servers in an organization that have a common authentication infrastructure. It seems that we can either: 1) Decide this is OK for SASL and thus OK for GSSAPI. 2) Decide that we don't actually get mutual authentication and remove that claim. 3) Fix the problem. --Sam From owner-ietf-sasl Wed Jul 23 13:00:23 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NK0Nqt067215 for ; Wed, 23 Jul 2003 13:00:23 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NK0Nbc067214 for ietf-sasl-bks; Wed, 23 Jul 2003 13:00:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NK0Mqt067209 for ; Wed, 23 Jul 2003 13:00:22 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h6NK06Gv014020; Wed, 23 Jul 2003 16:00:07 -0400 (EDT) Message-ID: <3F1EE9A1.7010601@oceana.com> Date: Wed, 23 Jul 2003 16:01:37 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Keith Burdis , "Raif S. Naffah" CC: SASL mailing list Subject: SRP security layer output 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: After working through the draft again in detail and attempting to bring the CMU implementation up to date, I found that the documented security layer output is suboptimal. The main problem that I found is that when no layer is active, the raw data still needs to be put into an EOS and then wrapped in a buffer. This means that the raw data would be prepended with three 4-byte lengths (counting the one already required by RFC 2222[bis]). I'm pretty sure that the other mechs that support security layers don't require the raw data to be encoded/decoded when no layer is active. I also don't see the point in wrapping the data segments into EOS and OS even when layers *are* active. Given the fact that SASL already requires the 4-byte length prepended to the output, and we know that the size of the HMAC is fixed, why not just append the HMAC to the raw/encrypted data and send them as plain bytes? The HMAC will always be the last 'hashlen' bytes and the data will always be the first 'inputlen-hashlen' bytes. So, I'm proposing this change to section 5.5 (Note that this eliminates the EOS data element from the spec): CP IP RD Peer sends/receives I I I bytes(p) I A I bytes(p) | IALG(Ki)( bytes(p) ) I A A bytes(p) | IALG(Ki)( bytes(p) | bytes(q) ) A I I bytes(c) A A I bytes(c) | IALG(Ki)( bytes(c) ) A A A bytes(c) | IALG(Ki)( bytes(c) | bytes(q) ) This allows applications and/or SASL implementations to short-circuit the no layer case (output = input) and potentially eliminates buffer copies resulting from the data wrapping. Also, with regards to the table, I think it makes it easier to read if the inactive layers are shown without any symbol (eg, remove the 'I's). Regards, Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Thu Jul 24 14:37:51 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OLbpqt074394 for ; Thu, 24 Jul 2003 14:37:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OLbpbB074393 for ietf-sasl-bks; Thu, 24 Jul 2003 14:37:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OLbhqt074363 for ; Thu, 24 Jul 2003 14:37:43 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id D95B7152495; Thu, 24 Jul 2003 17:37:30 -0400 (EDT) To: Ken Murchison Cc: Keith Burdis , "Raif S. Naffah" , SASL mailing list Subject: Re: SRP security layer output References: <3F1EE9A1.7010601@oceana.com> From: Sam Hartman Date: Thu, 24 Jul 2003 17:37:30 -0400 In-Reply-To: <3F1EE9A1.7010601@oceana.com> (Ken Murchison's message of "Wed, 23 Jul 2003 16:01:37 -0400") 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: The SASL mech should never use section 5 with all layers disabled. If the SASL mech is used without security layers, the application will never even pass the data to the SASL implementation. From owner-ietf-sasl Thu Jul 24 17:35:26 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6P0ZQqt084194 for ; Thu, 24 Jul 2003 17:35:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6P0ZQ50084193 for ietf-sasl-bks; Thu, 24 Jul 2003 17:35:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6P0ZOqt084121 for ; Thu, 24 Jul 2003 17:35:24 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (ny-kenton4a-a-83.buf.adelphia.net [24.51.28.83]) (authenticated bits=0) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h6P0ZAGw024653 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 24 Jul 2003 20:35:11 -0400 (EDT) Message-ID: <3F207B3B.3030402@oceana.com> Date: Thu, 24 Jul 2003 20:35:07 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. 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,pdf MIME-Version: 1.0 To: Sam Hartman CC: Keith Burdis , "Raif S. Naffah" , SASL mailing list Subject: Re: SRP security layer output References: <3F1EE9A1.7010601@oceana.com> In-Reply-To: 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: > The SASL mech should never use section 5 with all layers disabled. If > the SASL mech is used without security layers, the application will > never even pass the data to the SASL implementation. I agree, but that's not what is stated in Section 5 paragraph 3: "The data always passes through this three-stage filter, though any of the stages may be inactive. Only when a stage is active would the output be different from the input. In other words, if a stage is inactive, the octet sequence at the output side is an exact duplicate of the same sequence at the input side." This statement and the summary in Section 5.5 leads me to believe that the intention is to encode the data whether a security layer exists or not. I disagree with this (and the needless wrapping of the data elements), which is why I proposed my change. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Fri Jul 25 10:05:55 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PH5tqt071736 for ; Fri, 25 Jul 2003 10:05:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PH5tx0071735 for ietf-sasl-bks; Fri, 25 Jul 2003 10:05:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-TWO-SIXTY-TWO.MIT.EDU [18.187.6.7]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PH5rqt071730 for ; Fri, 25 Jul 2003 10:05:53 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 91CEC152496; Fri, 25 Jul 2003 13:05:52 -0400 (EDT) To: Ken Murchison Cc: Keith Burdis , "Raif S. Naffah" , SASL mailing list Subject: Re: SRP security layer output References: <3F1EE9A1.7010601@oceana.com> <3F207B3B.3030402@oceana.com> From: Sam Hartman Date: Fri, 25 Jul 2003 13:05:52 -0400 In-Reply-To: <3F207B3B.3030402@oceana.com> (Ken Murchison's message of "Thu, 24 Jul 2003 20:35:07 -0400") 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: >>>>> "Ken" == Ken Murchison writes: Ken> I agree, but that's not what is stated in Section 5 paragraph Ken> 3: Ken> "The data always passes through this three-stage filter, Ken> though any of the stages may be inactive. Only when a stage Ken> is active would the output be different from the input. In That's true only so long as section 5 is being referenced. Any other reading implies that this mechanism spec updates the base SASL spec. But I agree that the section on SASL should be clarified. From owner-ietf-sasl Fri Jul 25 13:07:03 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PK73qt084848 for ; Fri, 25 Jul 2003 13:07:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PK73ZI084847 for ietf-sasl-bks; Fri, 25 Jul 2003 13:07:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PK72qt084842 for ; Fri, 25 Jul 2003 13:07:02 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 282C4152496; Fri, 25 Jul 2003 16:06:48 -0400 (EDT) To: ietf-sasl@imc.org Subject: Draft minutes Message-Id: <20030725200648.282C4152496@konishi-polis.mit.edu> Date: Fri, 25 Jul 2003 16:06:48 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please send in comments or corrections by next Tuesday. I will send in for proceedings shortly after that point. IETF SASL WG meeting Minutes ========================== Tuesday 15 July 2003 3:45pm chairs: Sam Hartman Kurt Zeilenga scribe: Luke Howard 2222bis ======= - Alexei noted that he has published a subsequent revision of 2222bis; minor editorial issues remain - Clarification of empty authorization identities - Alexei will do a final revision of the document in the first week of August after which it can go to last call saslprep ======== - Sam noted that current belief is that this will meet the needs of the Kerberos community - The saslprep document is to be revised to include informational mapping tables but is otherwise ready for last call. New revision is expected shortly after the meeting and the last call will follow shortly after it is announced. DIGEST-MD5 ========== - DIGEST-MD5: Alexei noted that since the last revision he has made the following changes: - Clarifications regarding character sets and authorization vs authentication identities - reference to saslprep the last revision has been updated - Clarified RC4 cipher state is not reset between packets - merged AES cipher document with this one - no changes to solve the AES CBC mod attack: requested text be contributed once a solution is found. - The working group decided that AES for digest-md5 will use random IVs rather than counter mode. Counter mode is harder to implement correctly. - Questions from Sam regarding mandatory to implement ciphers: what should it be (if one is not already required)? - Sam believes there will be interest in making RC4 mandatory to implement because it is implemented now; there is no security reason to not do so that he was aware of - Kurt noted a question as to whether security layers were mandatory to implement; not wearing his chair hat he suggested that at least integrity should be mandatory, Alexei noted that many mail clients do authentication only - Chris Newman suggested that layers should not be mandatory because we already have TLS; suggest that vendors may remove support for DIGEST-MD5 entirely due to engineering cost of implementing layers - Kurt suggested SHOULD implement integrity and that security considerations should note that you are subject to MITM without TLS or layers - Noted that CRAM-MD5 is subject to the "evil server" attach which DIGEST-MD5 is not because there is a client nonce; also DIGEST-MD5 being compatible with HTTP digest has advantages. ie. there are sufficient advantages over CRAM-MD5 in spite of the lack of layers being mandatory to implement - Sam asked for consensus for deprecating both DES and triple DES. There were no objections, nor to taking them out of the document. Sam suggested that we note in the Security Considerations or Changes Since section as to why these were deprecated (preference for latter section) GSSAPI ====== - Sam noted draft was "eaten by the secretariat" - Plan is to move forward on it -- 00 to appear "soon" CRAM-MD5 ======== - A version with saslprep references is available SASL Applicability Statement ============================ - Keith Burdis agreed to submit an SASL applicability statement as an individual submission. His document will include comparisons of the various sasl mechanisms and their security properties. Sam agreed to propose an outline for the document. The working group will discuss rechartering to include this document after the first revision. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PK73qt084848 for ; Fri, 25 Jul 2003 13:07:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PK73ZI084847 for ietf-sasl-bks; Fri, 25 Jul 2003 13:07:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PK72qt084842 for ; Fri, 25 Jul 2003 13:07:02 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 282C4152496; Fri, 25 Jul 2003 16:06:48 -0400 (EDT) To: ietf-sasl@imc.org Subject: Draft minutes Message-Id: <20030725200648.282C4152496@konishi-polis.mit.edu> Date: Fri, 25 Jul 2003 16:06:48 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please send in comments or corrections by next Tuesday. I will send in for proceedings shortly after that point. IETF SASL WG meeting Minutes ========================== Tuesday 15 July 2003 3:45pm chairs: Sam Hartman Kurt Zeilenga scribe: Luke Howard 2222bis ======= - Alexei noted that he has published a subsequent revision of 2222bis; minor editorial issues remain - Clarification of empty authorization identities - Alexei will do a final revision of the document in the first week of August after which it can go to last call saslprep ======== - Sam noted that current belief is that this will meet the needs of the Kerberos community - The saslprep document is to be revised to include informational mapping tables but is otherwise ready for last call. New revision is expected shortly after the meeting and the last call will follow shortly after it is announced. DIGEST-MD5 ========== - DIGEST-MD5: Alexei noted that since the last revision he has made the following changes: - Clarifications regarding character sets and authorization vs authentication identities - reference to saslprep the last revision has been updated - Clarified RC4 cipher state is not reset between packets - merged AES cipher document with this one - no changes to solve the AES CBC mod attack: requested text be contributed once a solution is found. - The working group decided that AES for digest-md5 will use random IVs rather than counter mode. Counter mode is harder to implement correctly. - Questions from Sam regarding mandatory to implement ciphers: what should it be (if one is not already required)? - Sam believes there will be interest in making RC4 mandatory to implement because it is implemented now; there is no security reason to not do so that he was aware of - Kurt noted a question as to whether security layers were mandatory to implement; not wearing his chair hat he suggested that at least integrity should be mandatory, Alexei noted that many mail clients do authentication only - Chris Newman suggested that layers should not be mandatory because we already have TLS; suggest that vendors may remove support for DIGEST-MD5 entirely due to engineering cost of implementing layers - Kurt suggested SHOULD implement integrity and that security considerations should note that you are subject to MITM without TLS or layers - Noted that CRAM-MD5 is subject to the "evil server" attach which DIGEST-MD5 is not because there is a client nonce; also DIGEST-MD5 being compatible with HTTP digest has advantages. ie. there are sufficient advantages over CRAM-MD5 in spite of the lack of layers being mandatory to implement - Sam asked for consensus for deprecating both DES and triple DES. There were no objections, nor to taking them out of the document. Sam suggested that we note in the Security Considerations or Changes Since section as to why these were deprecated (preference for latter section) GSSAPI ====== - Sam noted draft was "eaten by the secretariat" - Plan is to move forward on it -- 00 to appear "soon" CRAM-MD5 ======== - A version with saslprep references is available SASL Applicability Statement ============================ - Keith Burdis agreed to submit an SASL applicability statement as an individual submission. His document will include comparisons of the various sasl mechanisms and their security properties. Sam agreed to propose an outline for the document. The working group will discuss rechartering to include this document after the first revision. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PH5tqt071736 for ; Fri, 25 Jul 2003 10:05:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PH5tx0071735 for ietf-sasl-bks; Fri, 25 Jul 2003 10:05:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-TWO-SIXTY-TWO.MIT.EDU [18.187.6.7]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PH5rqt071730 for ; Fri, 25 Jul 2003 10:05:53 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 91CEC152496; Fri, 25 Jul 2003 13:05:52 -0400 (EDT) To: Ken Murchison Cc: Keith Burdis , "Raif S. Naffah" , SASL mailing list Subject: Re: SRP security layer output References: <3F1EE9A1.7010601@oceana.com> <3F207B3B.3030402@oceana.com> From: Sam Hartman Date: Fri, 25 Jul 2003 13:05:52 -0400 In-Reply-To: <3F207B3B.3030402@oceana.com> (Ken Murchison's message of "Thu, 24 Jul 2003 20:35:07 -0400") 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: >>>>> "Ken" == Ken Murchison writes: Ken> I agree, but that's not what is stated in Section 5 paragraph Ken> 3: Ken> "The data always passes through this three-stage filter, Ken> though any of the stages may be inactive. Only when a stage Ken> is active would the output be different from the input. In That's true only so long as section 5 is being referenced. Any other reading implies that this mechanism spec updates the base SASL spec. But I agree that the section on SASL should be clarified. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6P0ZQqt084194 for ; Thu, 24 Jul 2003 17:35:26 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6P0ZQ50084193 for ietf-sasl-bks; Thu, 24 Jul 2003 17:35:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6P0ZOqt084121 for ; Thu, 24 Jul 2003 17:35:24 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (ny-kenton4a-a-83.buf.adelphia.net [24.51.28.83]) (authenticated bits=0) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h6P0ZAGw024653 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 24 Jul 2003 20:35:11 -0400 (EDT) Message-ID: <3F207B3B.3030402@oceana.com> Date: Thu, 24 Jul 2003 20:35:07 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. 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,pdf MIME-Version: 1.0 To: Sam Hartman CC: Keith Burdis , "Raif S. Naffah" , SASL mailing list Subject: Re: SRP security layer output References: <3F1EE9A1.7010601@oceana.com> In-Reply-To: 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: > The SASL mech should never use section 5 with all layers disabled. If > the SASL mech is used without security layers, the application will > never even pass the data to the SASL implementation. I agree, but that's not what is stated in Section 5 paragraph 3: "The data always passes through this three-stage filter, though any of the stages may be inactive. Only when a stage is active would the output be different from the input. In other words, if a stage is inactive, the octet sequence at the output side is an exact duplicate of the same sequence at the input side." This statement and the summary in Section 5.5 leads me to believe that the intention is to encode the data whether a security layer exists or not. I disagree with this (and the needless wrapping of the data elements), which is why I proposed my change. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OLbpqt074394 for ; Thu, 24 Jul 2003 14:37:51 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OLbpbB074393 for ietf-sasl-bks; Thu, 24 Jul 2003 14:37:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OLbhqt074363 for ; Thu, 24 Jul 2003 14:37:43 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id D95B7152495; Thu, 24 Jul 2003 17:37:30 -0400 (EDT) To: Ken Murchison Cc: Keith Burdis , "Raif S. Naffah" , SASL mailing list Subject: Re: SRP security layer output References: <3F1EE9A1.7010601@oceana.com> From: Sam Hartman Date: Thu, 24 Jul 2003 17:37:30 -0400 In-Reply-To: <3F1EE9A1.7010601@oceana.com> (Ken Murchison's message of "Wed, 23 Jul 2003 16:01:37 -0400") 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: The SASL mech should never use section 5 with all layers disabled. If the SASL mech is used without security layers, the application will never even pass the data to the SASL implementation. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NK0Nqt067215 for ; Wed, 23 Jul 2003 13:00:23 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NK0Nbc067214 for ietf-sasl-bks; Wed, 23 Jul 2003 13:00:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NK0Mqt067209 for ; Wed, 23 Jul 2003 13:00:22 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h6NK06Gv014020; Wed, 23 Jul 2003 16:00:07 -0400 (EDT) Message-ID: <3F1EE9A1.7010601@oceana.com> Date: Wed, 23 Jul 2003 16:01:37 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Keith Burdis , "Raif S. Naffah" CC: SASL mailing list Subject: SRP security layer output 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: After working through the draft again in detail and attempting to bring the CMU implementation up to date, I found that the documented security layer output is suboptimal. The main problem that I found is that when no layer is active, the raw data still needs to be put into an EOS and then wrapped in a buffer. This means that the raw data would be prepended with three 4-byte lengths (counting the one already required by RFC 2222[bis]). I'm pretty sure that the other mechs that support security layers don't require the raw data to be encoded/decoded when no layer is active. I also don't see the point in wrapping the data segments into EOS and OS even when layers *are* active. Given the fact that SASL already requires the 4-byte length prepended to the output, and we know that the size of the HMAC is fixed, why not just append the HMAC to the raw/encrypted data and send them as plain bytes? The HMAC will always be the last 'hashlen' bytes and the data will always be the first 'inputlen-hashlen' bytes. So, I'm proposing this change to section 5.5 (Note that this eliminates the EOS data element from the spec): CP IP RD Peer sends/receives I I I bytes(p) I A I bytes(p) | IALG(Ki)( bytes(p) ) I A A bytes(p) | IALG(Ki)( bytes(p) | bytes(q) ) A I I bytes(c) A A I bytes(c) | IALG(Ki)( bytes(c) ) A A A bytes(c) | IALG(Ki)( bytes(c) | bytes(q) ) This allows applications and/or SASL implementations to short-circuit the no layer case (output = input) and potentially eliminates buffer copies resulting from the data wrapping. Also, with regards to the table, I think it makes it easier to read if the inactive layers are shown without any symbol (eg, remove the 'I's). Regards, Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NDWlqt041677 for ; Wed, 23 Jul 2003 06:32:47 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NDWlVa041676 for ietf-sasl-bks; Wed, 23 Jul 2003 06:32:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NDWjqt041663 for ; Wed, 23 Jul 2003 06:32:46 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by luminous.mit.edu (Postfix, from userid 1000) id 76E2A76614; Wed, 23 Jul 2003 09:33:39 -0400 (EDT) To: Nicolas Williams Cc: ietf-sasl@imc.org, Keith Burdis , "Raif S. Naffah" Subject: Re: Comments on draft-burdis-cat-srp-sasl-08.txt References: <20030722232035.GD8918@binky.central.sun.com> From: Sam Hartman Date: Wed, 23 Jul 2003 09:33:39 -0400 In-Reply-To: <20030722232035.GD8918@binky.central.sun.com> (Nicolas Williams's message of "Tue, 22 Jul 2003 18:20:35 -0500") Message-ID: <87smox5pvw.fsf@luminous.mit.edu> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: To clarify, I don't believe that Nico's comments about mutual authentication actually are specific to the GSSAPI mechanism. The SRP SASL mechanism seems to only provide mutual authentication if the same password and verifier is used only on one server. I'm not sure how appropriate this is for a SASL mechanism; it seems like you will have difficulty distinguishing between servers in an organization that have a common authentication infrastructure. It seems that we can either: 1) Decide this is OK for SASL and thus OK for GSSAPI. 2) Decide that we don't actually get mutual authentication and remove that claim. 3) Fix the problem. --Sam Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6N4C9qt087807 for ; Tue, 22 Jul 2003 21:12:09 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6N4C9cT087806 for ietf-sasl-bks; Tue, 22 Jul 2003 21:12:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6N4C8qt087801 for ; Tue, 22 Jul 2003 21:12:08 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h6N4C8c6078307 for ; Wed, 23 Jul 2003 04:12:10 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030723060828.01b9cab8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 23 Jul 2003 06:08:52 +0200 To: ietf-sasl@imc.org From: Nicolas Williams Subject: draft-ietf-cat-sasl-gssapi-XX.txt && error tokens Mime-Version: 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 last version of draft-ietf-cat-sasl-gssapi that I saw (-05) did not appropriately deal with GSS-API error tokens. Yes, there is such a thing as GSS-API error tokens, that is, GSS_Accept_sec_context() (and init too) can return a major status other than GSS_S_COMPLETE/GSS_S_CONTINUE_NEEDED *and* output a token at the same time. Such tokens SHOULD be sent. Sending GSS-API error tokens makes debugging errors a lot easier and results in error strings that make sense being displayed to the user. Also note: minor status codes are generally not standardized (certainly not for the Kerberos V GSS mechanism) and so minor error codes should not be sent on the wire as the peer may not be able to interpret them correctly (this is definitely the case with the Kerberos mech). Since I cannot find a current version of draft-ietf-cat-sasl-gssapi I will refrain from proposing actual text changes for now. Cheers, Nico -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6N0SOqt080945 for ; Tue, 22 Jul 2003 17:28:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6N0SOtg080944 for ietf-sasl-bks; Tue, 22 Jul 2003 17:28:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6N0SNqt080939 for ; Tue, 22 Jul 2003 17:28:23 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6N0SQEJ002193 for ; Tue, 22 Jul 2003 18:28:26 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6N0SPbO015631 for ; Tue, 22 Jul 2003 18:28:25 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h6N0PCQx010126 for ; Tue, 22 Jul 2003 17:25:12 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6N0PBJ9010125 for ietf-sasl@imc.org; Tue, 22 Jul 2003 19:25:11 -0500 (CDT) Date: Tue, 22 Jul 2003 18:20:35 -0500 From: Nicolas Williams To: ietf-sasl@imc.org, Keith Burdis , "Raif S. Naffah" Cc: Sam Hartman Subject: Comments on draft-burdis-cat-srp-sasl-08.txt Message-ID: <20030722232035.GD8918@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The following comments all pertain to the GSS-API mechanism defined in section 8 of draft-burdis-cat-srp-sasl-08.txt except where otherwise noted: 1. Mutual Authentication & SRP GSS Principal Naming The I-D claims to provide mutual authentication, but does not provide for naming acceptors. While I appreciate that SRP provides mutual authentication, unless one can bind the SRP password and verifier to an acceptor name then the acceptor name MUST be of type GSS_C_NT_ANONYMOUS. Sam Hartman has proposed appending, prepending or otherwise stirring the acceptor name into the password as a way to achieve mutual authentication with non-anonymous acceptors. The I-D should explain the limitations of its mutual authentication provision and/or add acceptor naming to the protocol. (See questions below.) Initiator naming should also be discussed. Additional questions: Should services be able to use this mechanism as initiators? How about optionally running the SRP protocol in both directions so that the initiator and acceptor can mutually authenticate without having to stir GSS-API names into the password/verifier? The two exchanges would have to be mutually bound, sure, perhaps in the last message of the double exchange. (In this case the verifiers could even be published, as long as they are distributed in a secure fashion.) 2. Channel Bindings I imagine that the I-D authors may have thought that GSS channel bindings are an esoteric, barely used feature of the GSS-API. A few months ago they have been correct. This is about to change; the use of GSS-API channel bindings is being formalized and given new life, see: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt If the protocol can be extended to accommodate integrity protected channel bindings I highly encourage you to do so. You can always define the encoding of the channel bindings by reference to RFC1964, module choice of hash function (this is how we're defining them for SPKM in draft-ietf-nfsv4-ccm-01.txt). 3. No Error Token Is Specified The GSS-API does, apparent widely spread assumptions notwithstanding, support the use of error tokens - i.e., output tokens emitted by gss_init_sec_context() or gss_accept_sec_context() when they also return a major status code other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED. This problem is significant. Please fix. 4. Obsoleted RFCs Do Not Make for Good Normative References This I-D references RFC2078 instead of RFC2743. Please fix. :) Cheers, Nico -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MNPJqt079502 for ; Tue, 22 Jul 2003 16:25:19 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6MNPJim079501 for ietf-sasl-bks; Tue, 22 Jul 2003 16:25:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MNO1qt079476 for ; Tue, 22 Jul 2003 16:24:01 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6MNNpxk014025; Tue, 22 Jul 2003 16:23:51 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6MNNocm023415; Tue, 22 Jul 2003 17:23:50 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h6MNKaQx010075; Tue, 22 Jul 2003 16:20:36 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6MNKZWk010074; Tue, 22 Jul 2003 18:20:35 -0500 (CDT) Date: Tue, 22 Jul 2003 18:20:35 -0500 From: Nicolas Williams To: ietf-sasl@imc.org, Keith Burdis , "Raif S. Naffah" Cc: Sam Hartman Subject: Comments on draft-burdis-cat-srp-sasl-08.txt Message-ID: <20030722232035.GD8918@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The following comments all pertain to the GSS-API mechanism defined in section 8 of draft-burdis-cat-srp-sasl-08.txt except where otherwise noted: 1. Mutual Authentication & SRP GSS Principal Naming The I-D claims to provide mutual authentication, but does not provide for naming acceptors. While I appreciate that SRP provides mutual authentication, unless one can bind the SRP password and verifier to an acceptor name then the acceptor name MUST be of type GSS_C_NT_ANONYMOUS. Sam Hartman has proposed appending, prepending or otherwise stirring the acceptor name into the password as a way to achieve mutual authentication with non-anonymous acceptors. The I-D should explain the limitations of its mutual authentication provision and/or add acceptor naming to the protocol. (See questions below.) Initiator naming should also be discussed. Additional questions: Should services be able to use this mechanism as initiators? How about optionally running the SRP protocol in both directions so that the initiator and acceptor can mutually authenticate without having to stir GSS-API names into the password/verifier? The two exchanges would have to be mutually bound, sure, perhaps in the last message of the double exchange. (In this case the verifiers could even be published, as long as they are distributed in a secure fashion.) 2. Channel Bindings I imagine that the I-D authors may have thought that GSS channel bindings are an esoteric, barely used feature of the GSS-API. A few months ago they have been correct. This is about to change; the use of GSS-API channel bindings is being formalized and given new life, see: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt If the protocol can be extended to accommodate integrity protected channel bindings I highly encourage you to do so. You can always define the encoding of the channel bindings by reference to RFC1964, module choice of hash function (this is how we're defining them for SPKM in draft-ietf-nfsv4-ccm-01.txt). 3. No Error Token Is Specified The GSS-API does, apparent widely spread assumptions notwithstanding, support the use of error tokens - i.e., output tokens emitted by gss_init_sec_context() or gss_accept_sec_context() when they also return a major status code other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED. This problem is significant. Please fix. 4. Obsoleted RFCs Do Not Make for Good Normative References This I-D references RFC2078 instead of RFC2743. Please fix. :) Cheers, Nico -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MLsiqt073585 for ; Tue, 22 Jul 2003 14:54:44 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6MLsiWd073584 for ietf-sasl-bks; Tue, 22 Jul 2003 14:54:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MLshqt073569 for ; Tue, 22 Jul 2003 14:54:43 -0700 (PDT) (envelope-from william.fiveash@sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6MLseDZ020776 for ; Tue, 22 Jul 2003 14:54:40 -0700 (PDT) Received: from alton.central.sun.com (alton.Central.Sun.COM [129.153.128.101]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6MLsdcm022888; Tue, 22 Jul 2003 15:54:39 -0600 (MDT) Received: from alton.central.sun.com (localhost [127.0.0.1]) by alton.central.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6MLsdkY463134; Tue, 22 Jul 2003 16:54:39 -0500 (CDT) Received: (from willf@localhost) by alton.central.sun.com (8.12.9+Sun/8.12.9/Submit) id h6MLsdXB463133; Tue, 22 Jul 2003 16:54:39 -0500 (CDT) X-Authentication-Warning: alton.central.sun.com: willf set sender to william.fiveash@sun.com using -f Date: Tue, 22 Jul 2003 16:54:39 -0500 From: Will Fiveash To: ietf-sasl@imc.org Cc: Jeff Moore Subject: Fwd: [Nicolas.Williams@sun.com: draft-ietf-cat-sasl-gssapi-XX.txt && error tokens] Message-ID: <20030722215438.GI456254@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Since Nico isn't subscribed I'm forwarding this for him. -- Will Fiveash Sun Microsystems Inc. Austin, TX, USA (TZ=CST6CDT) ----- Forwarded message from Nicolas Williams ----- Date: Tue, 22 Jul 2003 13:28:16 -0700 From: Nicolas Williams To: ietf-sasl@imc.org Subject: draft-ietf-cat-sasl-gssapi-XX.txt && error tokens User-Agent: Mutt/1.4i The last version of draft-ietf-cat-sasl-gssapi that I saw (-05) did not appropriately deal with GSS-API error tokens. Yes, there is such a thing as GSS-API error tokens, that is, GSS_Accept_sec_context() (and init too) can return a major status other than GSS_S_COMPLETE/GSS_S_CONTINUE_NEEDED *and* output a token at the same time. Such tokens SHOULD be sent. Sending GSS-API error tokens makes debugging errors a lot easier and results in error strings that make sense being displayed to the user. Also note: minor status codes are generally not standardized (certainly not for the Kerberos V GSS mechanism) and so minor error codes should not be sent on the wire as the peer may not be able to interpret them correctly (this is definitely the case with the Kerberos mech). Since I cannot find a current version of draft-ietf-cat-sasl-gssapi I will refrain from proposing actual text changes for now. Cheers, Nico -- ----- End forwarded message ----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IGW6qt007102 for ; Fri, 18 Jul 2003 09:32:06 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6IGW6Yr007101 for ietf-sasl-bks; Fri, 18 Jul 2003 09:32:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IGW2qt007092 for ; Fri, 18 Jul 2003 09:32:03 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h6IGVmGv003090; Fri, 18 Jul 2003 12:31:48 -0400 (EDT) Message-ID: <3F18214A.2030706@oceana.com> Date: Fri, 18 Jul 2003 12:33:14 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Keith Burdis , "Raif S. Naffah" CC: SASL mailing list Subject: draft-burdis-cat-srp-sasl-08 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: Trying to bring Cyrus SASL in to compliance with the latest draft. Here are some notes I put together after a thorough read of the auth exchange. I may have more when I get into integrity and security. Section 3.8: > When such entities travel on the wire, they shall be encoded as > 4-octet Scalar Numbers. We shall use the syntax uint(n) to denote > the encoding of an Unsigned Integer n. In what byte-order? I assume big-endian. Section 4.5: > The server computes its evidence M2, which proves to the client that > it knows the shared context key K, as well as U, I and o, as follows: ^^^ > > H( bytes(A) > | bytes(M1) > | bytes(K) Was U removed from the calculation on purpose, or was it an oversight? If its no longer part of the calculation, then it should be removed from the sentence describing M2. > | bytes(H( bytes(I) )) > | bytes(H( bytes(o) )) > | bytes(sid) If sid is UTF8, should it be hashed, like I and o? > | ttl Shouldn't this be bytes(ttl)? > ) > > All parameters received from the client that are used as input to a > digest operation MUST be used as received. > > The server sends: > > { os(M2) | os(sIV) | sid | ttl } ^^^^^^^^^^ Shouldn't this be utf8(sid) and uint(ttl)? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GFLZqt086322 for ; Wed, 16 Jul 2003 08:21:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6GFLZVn086321 for ietf-sasl-bks; Wed, 16 Jul 2003 08:21:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu ([81.160.157.184]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GFLYqt086294 for ; Wed, 16 Jul 2003 08:21:34 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 21B06151D76; Wed, 16 Jul 2003 11:21:27 -0400 (EDT) To: Ken Murchison Cc: SASL mailing list Subject: Re: Summary of the SASL working group meeting References: <3F1554B6.9090601@oceana.com> From: Sam Hartman Date: Wed, 16 Jul 2003 11:21:27 -0400 In-Reply-To: <3F1554B6.9090601@oceana.com> (Ken Murchison's message of "Wed, 16 Jul 2003 09:35:50 -0400") 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: >>>>> "Ken" == Ken Murchison writes: Ken> Sam Hartman wrote: >> Keith Burdis agreed to submit an SASL applicability statement >> as an individual submission. His document will include >> comparisons of the various sasl mechanisms and their security >> properties. Sam agreed to propose an outline for the document. >> The working group will discuss rechartering to include this >> document after the first revision. Ken> How will this document differ from the following? Ken> http://www.ietf.org/internet-drafts/draft-iab-auth-mech-00.txt The IAB document seems to discuss mechanisms at a much lower level. I was invisioning comparing SASL to similar technologies like EAP, GSSAPI and TLS. And I was hoping to discuss sasl mechansims as sasl mechanisms. We should definitely point to the IAB document and when discussing mechanisms describe them in the category they fit into that framework. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GDYVqt082636 for ; Wed, 16 Jul 2003 06:34:31 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6GDYVsT082635 for ietf-sasl-bks; Wed, 16 Jul 2003 06:34:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GDYTqt082630 for ; Wed, 16 Jul 2003 06:34:29 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h6GDYPGv030702 for ; Wed, 16 Jul 2003 09:34:25 -0400 (EDT) Message-ID: <3F1554B6.9090601@oceana.com> Date: Wed, 16 Jul 2003 09:35:50 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: SASL mailing list Subject: Re: Summary of the SASL working group meeting References: In-Reply-To: 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: > Keith Burdis agreed to submit an SASL applicability statement as an > individual submission. His document will include comparisons of the > various sasl mechanisms and their security properties. Sam agreed to > propose an outline for the document. The working group will discuss > rechartering to include this document after the first revision. How will this document differ from the following? http://www.ietf.org/internet-drafts/draft-iab-auth-mech-00.txt -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6G86Xqt046115 for ; Wed, 16 Jul 2003 01:06:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6G86XDF046114 for ietf-sasl-bks; Wed, 16 Jul 2003 01:06:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu ([81.160.157.184]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6G86Wqt046108 for ; Wed, 16 Jul 2003 01:06:32 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id ED6AD151D60; Wed, 16 Jul 2003 04:06:23 -0400 (EDT) To: housley@vigilsec.com, smb@research.att.com Cc: ietf-sasl@imc.org Subject: Summary of the SASL working group meeting From: Sam Hartman Date: Wed, 16 Jul 2003 04:06:23 -0400 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: The SASL working group met on Tuesday for one hour. The document editor of RFC 2222bis (Alexei) will publish a revision in the first week of August at which point we will last call it. The saslprep document is to be revised to include informational mapping tables but is otherwise ready for last call. New revision is expected shortly after the meeting and the last call will follow shortly after it is announced. Working group participants who made comments during the plain or anonymous last call need to make sure their comments are reflected in the current document. The document editor believes that the working group is done with these two documents although we are not sending them to the IESG at this time. The working group decided that AES for digest-md5 will use random IVs rather than counter mode. Counter mode is harder to implement correctly. There is likely to be interest in making the RC4 cipher mandatory-to-implement for implementations that support confidentiality with digest-md5. The RC4 cipher is interoperable with existing implementations and we did not find any problems during the security review conducted after the last meeting. Currently, neither integrity protection nor confidentiality is mandatory-to-implement. At least one participant said he would remove digest-md5 support rather than implement integrity. The argument is that you can just use TLS. However, if you just use TLS, you need to depend on TLS to authenticate the server to the client or you have a man-in-the-mdille problem. This will be discussed on the list. The working group reached a consensus at the meeting to deprecate DES and 3DES because they are insecure. Larry submitted a 00 version of the GSSAPI draft, but it did not appear. He will resubmit in the near future. Keith Burdis agreed to submit an SASL applicability statement as an individual submission. His document will include comparisons of the various sasl mechanisms and their security properties. Sam agreed to propose an outline for the document. The working group will discuss rechartering to include this document after the first revision. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FGM2qt086896 for ; Tue, 15 Jul 2003 09:22:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6FGM2Re086895 for ietf-sasl-bks; Tue, 15 Jul 2003 09:22:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FGM1qt086890 for ; Tue, 15 Jul 2003 09:22:01 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h6FGM2g4018998; Tue, 15 Jul 2003 12:22:02 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h6FGM2jH007752; Tue, 15 Jul 2003 12:22:02 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h6FGM1U8009513; Tue, 15 Jul 2003 12:22:01 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h6FGM0YH015609; Tue, 15 Jul 2003 12:22:00 -0400 Subject: Re: Global state and libsasl From: Greg Hudson To: Jeff Moore Cc: "ietf-sasl@imc.org" In-Reply-To: <3F141CD8.AC475D3C@sun.com> References: <3F141CD8.AC475D3C@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1058286116.13068.69.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 15 Jul 2003 12:22:00 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2003-07-15 at 11:25, Jeff Moore wrote: > int _sasl_client_init(void *ctx, const sasl_callback_t *callbacks); What's with the leading underscores? Symbols like that are reserved for external linkage by the ANSI C standard. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FFPLqt084338 for ; Tue, 15 Jul 2003 08:25:21 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6FFPLtb084337 for ietf-sasl-bks; Tue, 15 Jul 2003 08:25:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FFPKqt084331 for ; Tue, 15 Jul 2003 08:25:20 -0700 (PDT) (envelope-from jeffrey.t.moore@sun.com) Received: from jurassic.eng.sun.com ([129.146.17.55]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6FFPLRi004171 for ; Tue, 15 Jul 2003 09:25:21 -0600 (MDT) Received: from sun.com (vpn-129-150-19-113.SFBay.Sun.COM [129.150.19.113]) by jurassic.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h6FFPKte268007 for ; Tue, 15 Jul 2003 08:25:20 -0700 (PDT) Message-ID: <3F141CD8.AC475D3C@sun.com> Date: Tue, 15 Jul 2003 08:25:12 -0700 From: Jeff Moore X-Mailer: Mozilla 4.79 (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "ietf-sasl@imc.org" Subject: Global state and libsasl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As has been previously discussed, libsasl maintains global state which can cause problems when both an application and one of its libraries use libsasl. The most recent suggestions on how to deal with this issue in a compatible way do not seem to address all the issues with global state in the Cyrus libsasl implementation. The Cyrus 2.x libsasl implementation uses global state for the following: 1. Loading plugins If an application decides which plugins to load and how to configure them, any other consumers of libsasl may not not have their needs met. Additionally, some plugins may be specific to a given application or library. They may not want the plugin to be used by other components. There are a number of ways there could be problems: a. Location of plugins (SASL_CB_GETPATH) Through the SASL_CB_GETPATH callback. If this callback is specified, libsasl will use the specified path to locate plugins. The specified path may not include the standard plugins - or it may include "private" plugins. b. Verification of plugins/configuration (SASL_CB_VERIFYFILE) Through the SASL_CB_VERIFYFILE callback. What one component may accept another might reject. c. logging of non-connection oriented problems (SASL_CB_LOG) libraries will not be able to report these sorts of problems themselves. d. Setting any global plugin configuration data: e.g. DIGEST-MD5 - reauth_timeout, GSSAPI - keytab KERBEROS_4 - srvtab SRP - srp_mda The way to set these today is via the getopt function registered in the global callback. Also note that for things like reauth_timeout, you may not want to share it between different components. e. Loading application/library specific plugins Any plugin that is loaded via sasl_xxx_add_plugin will be available to application or libraries. f. Loading application/library private plugins 2. memory allocation sasl_set_alloc() setting memory allocation functions may have unintended interactions between application and libraries. If the library has already used libsasl to perform some memory allocations before the application has set sasl_set_alloc(), bad things may happen. 3. mutex functions sasl_set_mutex() setting mutex allocation functions may have unintended interactions between applications and libraries. If this function is a MUST, what should a library do? 4. sasl_xxx_init() and sasl_done() Count of usage may deal with this - although no separation between client and server and potential for misbehaving applications/libraries to break others. 5. Global callbacks If specified, they will apply to both application and libraries. The application's global callbacks may end up handling callbacks for the library. If, as has been proposed, that libraries should not use global callbacks, the application will not see this problem. 6. Server sasl option configuration file Just as with global callbacks, options may be set for library that are not expected or wanted. 7. Requirement of non-thread-safe initialization. Ideally, we would all like to see the global state problem be solved with a minimum of changes to the existing semantics. One way to address much of the above is to introduce a sasl global context that would be inferred by the current sasl API, but which would allow libraries (or applications) to use libsasl independently of each other. (There are additional issues for sasl_set_alloc() and sasl_set_mutex().) This approach would introduce a number of new functions: void *sasl_create_context(void) Create a sasl global context - the current global state would be now associated with the created context. void sasl_free_context(void *ctx) Release all resources associated with the sasl global context. This would be semantically the same as the current sasl_done(). int _sasl_client_init(void *ctx, const sasl_callback_t *callbacks); Initialize the sasl global context for sasl client access. int _sasl_client_new(void *ctx, const char *service, ...) Create a sasl client connection using the sasl global context. int _sasl_server_init(void *ctx, const sasl_callback_t *callbacks, ...); Initialize the sasl global context for sasl server access. int _sasl_server_new(void *ctx, const char *service, ...) Create a sasl server connection using the sasl global context. int _sasl_client_add_plugin(void *ctx, const char *plugname, ...); int _sasl_server_add_plugin(void *ctx, const char *plugname, ...); int _sasl_canonuser_add_plugin(void *ctx, const char *plugname, ...); int _sasl_auxprop_add_plugin(void *ctx, const char *plugname, ...); Add plugins to the sasl global context The functions sasl_set_mutex() and sasl_global_listmech() would be deprecated. If sasl_set_alloc() is not deprecated, then _sasl_set_alloc(void *ctx, ...) could be defined. This approach would preserve the existing semantic and avoid: global state issues when a library initializes the libsasl before the application, the potential problem of applications getting callbacks for libraries and plugins installed by one component being available for use by other components. Cheers, Jeff Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6E76uqt034338 for ; Mon, 14 Jul 2003 00:06:56 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6E76ssb034332 for ietf-sasl-bks; Mon, 14 Jul 2003 00:06:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6E76oqt034320 for ; Mon, 14 Jul 2003 00:06:53 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h6E76hc6080394; Mon, 14 Jul 2003 07:06:44 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030714035247.01cda048@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 14 Jul 2003 03:56:41 +0200 To: "William Curley" From: "Kurt D. Zeilenga" Subject: Re: SASL w/auxprop(mysql) and shadow {Scanned} Cc: In-Reply-To: <000a01c3481c$c96eecc0$0600a8c0@dejour> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As this list is for discussion regarding current and future SASL standardization efforts and, in particular, the work of the IETF SASL working group, your post is off topic. I suggest you direct your post to a list concerning CMU's Cyrus SASL implementation, e.g., . Kurt, IETF SASL WG co-chair At 04:24 AM 7/12/2003, William Curley wrote: >I am trying to allow Postfix to authenticate via SASL to send email, SASL will either use the local shadow file or a mysql database to do the authentication. I currently have this setup more or less using 'saslauthd -a pam' and mysql-pam. I'd really like to just use SASL since it appears to support this. I understand that auxprop can connect to a mysql database, how do I start auxprop so it can do this? Or do I need to do this? With both pwcheck and saslauthd I've had to have the daemons running for it to work. Lastly, is it even possible to have SASL try to authenticate to both shadow and mysql at the same time? Thanks kindly for any light you can shed on this. > > >William Curley >wpc4@dodgethis.org >http://www.dodgethis.org - Free email and more. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6CAZaqt076201 for ; Sat, 12 Jul 2003 03:35:36 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6CAZa48076200 for ietf-sasl-bks; Sat, 12 Jul 2003 03:35:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6CAZVqt076194 for ; Sat, 12 Jul 2003 03:35:35 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust97.tnt102.lnd4.gbr.da.uu.net [213.116.52.97]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h6CAdAV03350; Sat, 12 Jul 2003 04:39:10 -0600 Message-ID: <3F0F3D08.F71EEEEF@isode.com> Date: Fri, 11 Jul 2003 16:41:12 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: Proposed Agenda References: <3F0DD586.77AD0B39@isode.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Can we also have a virtual "show of hands" for people who are planning to attend? > Please send replies to me and I will post the list to the mailing list. So far I've received only two replies from Sam Hartman and Keith Burdis. Kurt Zeilenga should be also in Vienna. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6C2OZqt035790 for ; Fri, 11 Jul 2003 19:24:35 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6C2OZm8035789 for ietf-sasl-bks; Fri, 11 Jul 2003 19:24:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smith.dodgethis.org (postfix@netblock-66-159-211-115.dslextreme.com [66.159.211.115]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6C2OXqt035784 for ; Fri, 11 Jul 2003 19:24:33 -0700 (PDT) (envelope-from wpc4@dodgethis.org) Received: from dejour (dejour.dodgethis.org [192.168.0.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smith.dodgethis.org (Postfix) with ESMTP id 22ABA37ACC for ; Fri, 11 Jul 2003 19:24:34 -0700 (PDT) Message-ID: <000a01c3481c$c96eecc0$0600a8c0@dejour> From: "William Curley" To: Subject: SASL w/auxprop(mysql) and shadow {Scanned} Date: Fri, 11 Jul 2003 19:24:56 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C347E2.1C5D6690" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C347E2.1C5D6690 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am trying to allow Postfix to authenticate via SASL to send email, = SASL will either use the local shadow file or a mysql database to do the = authentication. I currently have this setup more or less using = 'saslauthd -a pam' and mysql-pam. I'd really like to just use SASL since = it appears to support this. I understand that auxprop can connect to a = mysql database, how do I start auxprop so it can do this? Or do I need = to do this? With both pwcheck and saslauthd I've had to have the daemons = running for it to work. Lastly, is it even possible to have SASL try to = authenticate to both shadow and mysql at the same time? Thanks kindly = for any light you can shed on this. William Curley wpc4@dodgethis.org http://www.dodgethis.org - Free email and more. ------=_NextPart_000_0007_01C347E2.1C5D6690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am trying to allow Postfix to = authenticate via=20 SASL to send email, SASL will either use the local shadow file or a = mysql=20 database to do the authentication. I currently have this setup more or = less=20 using 'saslauthd -a pam' and mysql-pam. I'd really like to just use SASL = since=20 it appears to support this. I understand that auxprop can connect to a = mysql=20 database, how do I start auxprop so it can do this? Or do I need to do = this?=20 With both pwcheck and saslauthd I've had to have the daemons running for = it to=20 work. Lastly, is it even possible to have SASL try to authenticate to = both=20 shadow and mysql at the same time? Thanks kindly for any light you can = shed on=20 this.
 
 
William Curley
wpc4@dodgethis.org
http://www.dodgethis.org - Free = email and=20 more.
------=_NextPart_000_0007_01C347E2.1C5D6690-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6ALt5qt019518 for ; Thu, 10 Jul 2003 14:55:05 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6ALt5KP019517 for ietf-sasl-bks; Thu, 10 Jul 2003 14:55:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6ALswqt019503 for ; Thu, 10 Jul 2003 14:55:04 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust29.tnt101.lnd4.gbr.da.uu.net [213.116.50.29]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h6ALwSV18970; Thu, 10 Jul 2003 15:58:30 -0600 Message-ID: <3F0DD586.77AD0B39@isode.com> Date: Thu, 10 Jul 2003 15:07:18 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Proposed Agenda References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Hartman wrote: > People should speak up today if there are other issues that need to be covered. > > 1) preliminary stuff - 5m > 2) 2222bis - 15m > 3) saslprep - 15m > 4) other issues - 15m > 5) open mic - remainder There is a 50% chance that I will not be in Vienna (and there is some probability that even if I will be, I might miss the SASL meeting). Any takers to serve as proxy for me (i.e. 2222bis document and DIGEST-MD5)? Can we also have a virtual "show of hands" for people who are planning to attend? Please send replies to me and I will post the list to the mailing list. I am not sure what is included in "other issues", but some potential topics for discussion: 1). SASL C API (out of scope, but a lot of discussion lately) 2). Status of GSSAPI draft now that the base32 document is an RFC? Also, I've asked Application Area ADs for a slot to talk about HTTP SASL during Application Area Open Meeting on Monday. Assuming there is time, Peter Yee from RSA will present if I am not present. Cheers, Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67HNXqt079048 for ; Mon, 7 Jul 2003 10:23:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h67HNX3s079047 for ietf-sasl-bks; Mon, 7 Jul 2003 10:23:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (HOTASS-3.MIT.EDU [18.101.1.43]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67HNWqt079042 for ; Mon, 7 Jul 2003 10:23:32 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 6443915201D; Mon, 7 Jul 2003 13:23:33 -0400 (EDT) To: ietf-sasl@imc.org Subject: Proposed Agenda From: Sam Hartman Date: Mon, 07 Jul 2003 13:23:33 -0400 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: People should speak up today if there are other issues that need to be covered. 1) preliminary stuff - 5m 2) 2222bis - 15m 3) saslprep - 15m 4) other issues - 15m 5) open mic - remainder Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h664qWqt013065 for ; Sat, 5 Jul 2003 21:52:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h664qWAX013064 for ietf-sasl-bks; Sat, 5 Jul 2003 21:52:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-TWO-SIXTY-TWO.MIT.EDU [18.187.6.7]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h664pAqt013041 for ; Sat, 5 Jul 2003 21:51:10 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 7A798151D96; Sun, 6 Jul 2003 00:51:02 -0400 (EDT) To: Alexey Melnikov Cc: Greg Hudson , Rob Siemborski , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> From: Sam Hartman Date: Sun, 06 Jul 2003 00:51:02 -0400 In-Reply-To: <3F04ADD2.31E16D8B@isode.com> (Alexey Melnikov's message of "Thu, 03 Jul 2003 16:27:30 -0600") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Alexey" == Alexey Melnikov writes: Alexey> Ok people. I am afraid we are starting a religious war at Alexey> this point and this is not going to do us any good. If this were a WG item I'd disagree that anyone was proposing a religious war. I'd comment that there seems to be an unspecified requirement behind the global getopt callback. I'd ask the proponents of that callback to describe clearly what problem it was trying to solve. Then, I'd see if the WG could reach consensus on whether that problem was a good thing to solve in a standards track API. If the WG reached consensus on a problem and agreed the problem was worth solving, then we would look at whether the getopt callback actually solved that problem. But this document is not a WG item; you can use whatever procedure you like to decide its contents. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64Fl0qt096345 for ; Fri, 4 Jul 2003 08:47:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64Fl0r0096344 for ietf-sasl-bks; Fri, 4 Jul 2003 08:47:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64Fkxqt096337 for ; Fri, 4 Jul 2003 08:46:59 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h64Fkwc6086291; Fri, 4 Jul 2003 15:46:58 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030704084120.01c76430@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 04 Jul 2003 08:43:53 -0700 To: Rob Siemborski From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-sasl-anon-02.txt Cc: ietf-sasl@imc.org In-Reply-To: References: <200307022034.QAA13327@ietf.org> <200307022034.QAA13327@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 11:35 AM 7/3/2003, Rob Siemborski wrote: >On Wed, 2 Jul 2003 Internet-Drafts@ietf.org wrote: > > >> Title : The Anonymous SASL Mechanism >> Author(s) : K. Zeilenga >> Filename : draft-ietf-sasl-anon-02.txt > >>> >...not part of SASL itself. Newer profiles of SASL will include the >client message with the AUTHENTICATE command itself so the extra round >trip below (the server response with an empty "+ ") can be eliminated. ><< > >Seems to indicate a requirement on new SASL profiles, which is outside of >the scope of the document. However, it is reasonable to add some >clarification that the extra round trip is an artifact of the IMAP >profile. > >How about something more like: > >...not part of SASL itself. Additionally, protocols with SASL profiles >permitting an initial client response will be able to avoid the extra >round trip below (the server response with an empty "+ "). This sounds like a reasonable suggestion... Kurt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64Fbnqt095264 for ; Fri, 4 Jul 2003 08:37:49 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64Fbn3a095263 for ietf-sasl-bks; Fri, 4 Jul 2003 08:37:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64Fblqt095256 for ; Fri, 4 Jul 2003 08:37:47 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp6.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h64Fblil005193; Fri, 4 Jul 2003 11:37:47 -0400 Date: Fri, 4 Jul 2003 11:37:47 -0400 (EDT) From: Rob Siemborski To: Greg Hudson cc: ietf-sasl@imc.org Subject: Re: Using SASL C API from a library In-Reply-To: <1057332439.12524.484.camel@error-messages.mit.edu> Message-ID: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> <1057272175.12524.444.camel@error-messages.mit.edu> <3F057561.23539745@isode.com> <1057329958.12524.476.camel@error-messages.mit.edu> <1057332439.12524.484.camel@error-messages.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 Fri, 4 Jul 2003, Greg Hudson wrote: > > I also worry a bit about sasl_xxx_init not being required to be called > > from a single non-threaded environment, since in order to simulate this > > the library would need to lock around it. If sasl_set_mutex has been > > called, presumably this means that sasl_set_mutex allocates the necessary > > mutex, but now we can never release this mutex safely (well, unless > > sasl_set_mutex was called again with all NULL values, I suppose). This > > may not be a practical concern. > > pthreads allows you to create a statically intialized mutex. You'd > never release such a beast; you'd just use it to lock around > non-thread-safe operations. That's true. However, if sasl_set_mutex *is* called we have no way of staticly allocating a mutex, since we have to dynamicly call the init function to get the proper mutex (and we may not be using pthread mutexes). -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.9/8.12.8) with ESMTP id h64FRVqt094204 for ; Fri, 4 Jul 2003 08:27:31 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64FRVG4094203 for ietf-sasl-bks; Fri, 4 Jul 2003 08:27:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64FRUqt094198 for ; Fri, 4 Jul 2003 08:27:30 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h64FRUIi016142; Fri, 4 Jul 2003 11:27:30 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h64FRPcd011263; Fri, 4 Jul 2003 11:27:30 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h64FRNU8009085; Fri, 4 Jul 2003 11:27:24 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h64FRK9e026733; Fri, 4 Jul 2003 11:27:20 -0400 Subject: Re: Using SASL C API from a library From: Greg Hudson To: Rob Siemborski Cc: ietf-sasl@imc.org In-Reply-To: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> <1057272175.12524.444.camel@error-messages.mit.edu> <3F057561.23539745@isode.com> <1057329958.12524.476.camel@error-messages.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057332439.12524.484.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 04 Jul 2003 11:27:20 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I understand not wanting to make incompatible changes to the API at this time. On Fri, 2003-07-04 at 11:16, Rob Siemborski wrote: > If this change allows for implementations to advertise thread safety only > if sasl_set_mutex is called (from a non-threaded environment), I'm at least > willing to talk about this. Well, as long as they're clear, they can hedge all they want, I suppose. > I also worry a bit about sasl_xxx_init not being required to be called > from a single non-threaded environment, since in order to simulate this > the library would need to lock around it. If sasl_set_mutex has been > called, presumably this means that sasl_set_mutex allocates the necessary > mutex, but now we can never release this mutex safely (well, unless > sasl_set_mutex was called again with all NULL values, I suppose). This > may not be a practical concern. pthreads allows you to create a statically intialized mutex. You'd never release such a beast; you'd just use it to lock around non-thread-safe operations. > The callbacks argument is the default list of callbacks (see section 3.1.1 > for definition of sasl_callback_t structure). Libraries that are clients > of the API MUST supply NULL For this parameter. Applications that are > clients of the API MAY supply a list that includes the sasl_getopt_t > callback, but MUST NOT supply any other callbacks through this interface. That looks okay to me. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64FG2qt093945 for ; Fri, 4 Jul 2003 08:16:02 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64FG2IG093944 for ietf-sasl-bks; Fri, 4 Jul 2003 08:16:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64FG1qt093939 for ; Fri, 4 Jul 2003 08:16:01 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h64FG1uO014471; Fri, 4 Jul 2003 11:16:01 -0400 Date: Fri, 4 Jul 2003 11:16:00 -0400 (EDT) From: Rob Siemborski To: Greg Hudson cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library In-Reply-To: <1057329958.12524.476.camel@error-messages.mit.edu> Message-ID: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> <1057272175.12524.444.camel@error-messages.mit.edu> <3F057561.23539745@isode.com> <1057329958.12524.476.camel@error-messages.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 Fri, 4 Jul 2003, Greg Hudson wrote: > On Fri, 2003-07-04 at 08:38, Alexey Melnikov wrote: > > Sorry, forgot about that. Either an application should pass NULL as a library (and > > new function is introduced for setting getopt as described), or the application is > > only allowed to set getopt as a global callback. In this case interaction between > > global callbacks and local one should be documented. > > It sounds like we get the simplest transition if we make the changes: > > * Libraries must pass NULL for the global callbacks. > * Applications must pass NULL, or only a getopt callback. > * Applications MAY pass a getopt callback, but we don't say they > SHOULD. > > Existing SASL implementations don't have to do anything except modify > their documentation. I'm okay with this. > To resolve my other issue while still preserving the ability to use a > non-standard thread library: > > * sasl_set_mutex() becomes optional, but must be called from the > initial single-threaded environment if it is called at all. If > it is not called, the library will use the most standard native > thread APIs to protect any internal global state. > * sasl_*_init() no longer needs to be called from the initial > single-threaded environment. > > This change is more burdensome.for existing implementations which have > internal global state to protect; they must use threads (I'm told the > pthreads API works under Windows, but I don't know how advisable it is > to use it) and introduce a link-time dependency on a threads library. > But the API does then become safely usable from a library. > > (I am okay with allowing implementations to simply not advertise thread > safety, in which case they don't need to implement their own locks.) If this change allows for implementations to advertise thread safety only if sasl_set_mutex is called (from a non-threaded environment), I'm at least willing to talk about this. First, I think that calling sasl_set_mutex needs to be a "SHOULD" and not "OPTIONAL". I also worry a bit about sasl_xxx_init not being required to be called from a single non-threaded environment, since in order to simulate this the library would need to lock around it. If sasl_set_mutex has been called, presumably this means that sasl_set_mutex allocates the necessary mutex, but now we can never release this mutex safely (well, unless sasl_set_mutex was called again with all NULL values, I suppose). This may not be a practical concern. > These changes do not turn the API into a shining example of standard API > design in my book, of course; they are merely proposed as a practical > compromise. As you can probably understand, its really hard for me to not oppose significant changes in the API as we try to standardize it. We've already implemented two substantially different SASL APIs, I'm not looking forward to doing it a third time, especially given the deployment we currently have. Making it usable is one thing (for which I am willing to compromise), however making it a "shining example of API design" in ways that are not backwards compatible, just for the sake of doing so is probably going to see pushback. > The most important callback is the "getopt" callback (see > section 3.3.3) which is used to retrieve security policy option set- > tings from the caller's preferences. > > This text worries me because the getopt callback is referred to as > "important" and because security policy should be retrieved through a > fully standard interface. (That may require a lot of work; I haven't > thought about that problem in great detail.) Imagine trying to build an > application which has a GUI to configure security policy preferences > using the current design. I tend to agree that "security policy" decisions should be done through standard interfaces. Of course, if things like telling the mechanisms what database to pull user secrets from (or how to authenticate to that database, or so on) is a "security policy" decision, we're going to have problems defining any standard interface to deal with this. I think this sentence can just be eliminated, it doesn't really add anything useful to section 3.3.1. > The callbacks argument is the default list of callbacks (see sec- > tion 3.1.1 for definition of sasl_callback_t structure) and SHOULD > include the sasl_getopt_t callback (see section 3.3.3). > > This text worries me because, again, it seems to expect that the > implementation will really want to see a getopt callback and will behave > only minimally usefully without one. I'm willing to change SHOULD to a MAY here (for applications), and MUST NOT (for libraries). Something like: The callbacks argument is the default list of callbacks (see section 3.1.1 for definition of sasl_callback_t structure). Libraries that are clients of the API MUST supply NULL For this parameter. Applications that are clients of the API MAY supply a list that includes the sasl_getopt_t callback, but MUST NOT supply any other callbacks through this interface. -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.9/8.12.8) with ESMTP id h64EkGqt091563 for ; Fri, 4 Jul 2003 07:46:16 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64EkGCo091562 for ietf-sasl-bks; Fri, 4 Jul 2003 07:46:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64EkEqt091557 for ; Fri, 4 Jul 2003 07:46:15 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h64EkFIi009942; Fri, 4 Jul 2003 10:46:15 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h64Ek52e010251; Fri, 4 Jul 2003 10:46:05 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h64Ek4FJ027290; Fri, 4 Jul 2003 10:46:04 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h64Ek3Ai026695; Fri, 4 Jul 2003 10:46:03 -0400 Subject: Re: Using SASL C API from a library From: Greg Hudson To: Alexey Melnikov Cc: ietf-sasl@imc.org In-Reply-To: <3F057561.23539745@isode.com> References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> <1057272175.12524.444.camel@error-messages.mit.edu> <3F057561.23539745@isode.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057329958.12524.476.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 04 Jul 2003 10:46:03 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 2003-07-04 at 08:38, Alexey Melnikov wrote: > Sorry, forgot about that. Either an application should pass NULL as a library (and > new function is introduced for setting getopt as described), or the application is > only allowed to set getopt as a global callback. In this case interaction between > global callbacks and local one should be documented. It sounds like we get the simplest transition if we make the changes: * Libraries must pass NULL for the global callbacks. * Applications must pass NULL, or only a getopt callback. * Applications MAY pass a getopt callback, but we don't say they SHOULD. Existing SASL implementations don't have to do anything except modify their documentation. To resolve my other issue while still preserving the ability to use a non-standard thread library: * sasl_set_mutex() becomes optional, but must be called from the initial single-threaded environment if it is called at all. If it is not called, the library will use the most standard native thread APIs to protect any internal global state. * sasl_*_init() no longer needs to be called from the initial single-threaded environment. This change is more burdensome.for existing implementations which have internal global state to protect; they must use threads (I'm told the pthreads API works under Windows, but I don't know how advisable it is to use it) and introduce a link-time dependency on a threads library. But the API does then become safely usable from a library. (I am okay with allowing implementations to simply not advertise thread safety, in which case they don't need to implement their own locks.) These changes do not turn the API into a shining example of standard API design in my book, of course; they are merely proposed as a practical compromise. Rob Siemborski wrote: > So option names would still be non-standard? Doesn't this not address > Greg's concern then? There are my concerns about the API's practical usability from a library, and there are my concerns about good design of a standard API, and I haven't kept them separate in this discussion. The former concerns are mostly objective, but it's clear that the other members of this working group don't agree with me on the latter concerns, so I will try to stick to the former. With that proviso, having a pseudo-standardized getopt() is okay as long as we don't enforce its use by callers. So I have concerns with the following text in the current draft: The most important callback is the "getopt" callback (see section 3.3.3) which is used to retrieve security policy option set- tings from the caller's preferences. This text worries me because the getopt callback is referred to as "important" and because security policy should be retrieved through a fully standard interface. (That may require a lot of work; I haven't thought about that problem in great detail.) Imagine trying to build an application which has a GUI to configure security policy preferences using the current design. The callbacks argument is the default list of callbacks (see sec- tion 3.1.1 for definition of sasl_callback_t structure) and SHOULD include the sasl_getopt_t callback (see section 3.3.3). This text worries me because, again, it seems to expect that the implementation will really want to see a getopt callback and will behave only minimally usefully without one. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64EWaqt090184 for ; Fri, 4 Jul 2003 07:32:36 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64EWatw090183 for ietf-sasl-bks; Fri, 4 Jul 2003 07:32:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64EWZqt090176 for ; Fri, 4 Jul 2003 07:32:35 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (82-43-138-23.cable.ubr01.newm.blueyonder.co.uk [82.43.138.23]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h64EaFV14473; Fri, 4 Jul 2003 08:36:15 -0600 Message-ID: <3F058FFF.E7D32D15@isode.com> Date: Fri, 04 Jul 2003 08:32:31 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Siemborski CC: Greg Hudson , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> <3F057089.DE9855FB@isode.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: > On Fri, 4 Jul 2003, Alexey Melnikov wrote: > > > > I don't see how this is better than allowing a getopt() callback to be set > > > by the application, but not by libraries in the call to sasl_xxx_init(). > > > > Would you rather allow getopt (and only getopt) to be set by the > > application when calling a sasl_xxx_init() and a library using SASL > > always pass NULL as callbacks? > > Yes, since it is much closer to what is currently done, and I don't see > the gain of adding a separate "set getopt" function which needs to be > called before sasl_xxx_init anyway. If there's a concrete gain that > justified the change in code, I'd be less opposed. > > > > Not quite true, this requires standardizing the name of an option, as > > > well. > > > > I meant in Cyrus SASL library, not the document. > > So option names would still be non-standard? Doesn't this not address > Greg's concern then? I think it should be standard, but Greg wouldn't care :-). Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64ETbqt089725 for ; Fri, 4 Jul 2003 07:29:37 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64ETb4t089724 for ietf-sasl-bks; Fri, 4 Jul 2003 07:29:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64ETVqt089704 for ; Fri, 4 Jul 2003 07:29:31 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h64ETVuO013505; Fri, 4 Jul 2003 10:29:31 -0400 Date: Fri, 4 Jul 2003 10:29:31 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: Greg Hudson , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library In-Reply-To: <3F057089.DE9855FB@isode.com> Message-ID: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> <3F057089.DE9855FB@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 4 Jul 2003, Alexey Melnikov wrote: > > I don't see how this is better than allowing a getopt() callback to be set > > by the application, but not by libraries in the call to sasl_xxx_init(). > > Would you rather allow getopt (and only getopt) to be set by the > application when calling a sasl_xxx_init() and a library using SASL > always pass NULL as callbacks? Yes, since it is much closer to what is currently done, and I don't see the gain of adding a separate "set getopt" function which needs to be called before sasl_xxx_init anyway. If there's a concrete gain that justified the change in code, I'd be less opposed. > > Not quite true, this requires standardizing the name of an option, as > > well. > > I meant in Cyrus SASL library, not the document. So option names would still be non-standard? Doesn't this not address Greg's concern then? -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.9/8.12.8) with ESMTP id h64Cd3qt086288 for ; Fri, 4 Jul 2003 05:39:03 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64Cd3j0086287 for ietf-sasl-bks; Fri, 4 Jul 2003 05:39:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64Cd2qt086282 for ; Fri, 4 Jul 2003 05:39:02 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (82-43-138-23.cable.ubr01.newm.blueyonder.co.uk [82.43.138.23]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h64CgfV13699; Fri, 4 Jul 2003 06:42:42 -0600 Message-ID: <3F057561.23539745@isode.com> Date: Fri, 04 Jul 2003 06:38:57 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg Hudson CC: ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> <1057272175.12524.444.camel@error-messages.mit.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greg Hudson wrote: > On Thu, 2003-07-03 at 18:27, Alexey Melnikov wrote: > > So, how about making some constructive suggestions. How about the following: > > 1). libraries MUST NOT specify callbacks when calling > > sasl_client_init/sasl_server_init. > > Global callbacks are thus deprecated. > > You seem to leave open the question of whether applications are allowed > to specify callbacks. Sorry, forgot about that. Either an application should pass NULL as a library (and new function is introduced for setting getopt as described), or the application is only allowed to set getopt as a global callback. In this case interaction between global callbacks and local one should be documented. > Was that intentional? No. > (As I've mentioned before, if applications are allowed to set global > callbacks, then a library using SASL cannot guard against accidentally > triggering the application global callbacks.) > > > 2). a new function is added to set getopt callback. An application that doesn't > > care about getopt, will not call this function. > > Well, as everybody knows, my religion does not include such a device, > but global state is generally not burdensome as long as it's > (completely) optional. So I won't scream and yell about it. I was hoping for this :-). Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64CIPqt085751 for ; Fri, 4 Jul 2003 05:18:25 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64CIPZ2085750 for ietf-sasl-bks; Fri, 4 Jul 2003 05:18:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64CIOqt085745 for ; Fri, 4 Jul 2003 05:18:24 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (82-43-138-23.cable.ubr01.newm.blueyonder.co.uk [82.43.138.23]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h64CM1V13552; Fri, 4 Jul 2003 06:22:01 -0600 Message-ID: <3F057089.DE9855FB@isode.com> Date: Fri, 04 Jul 2003 06:18:17 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Siemborski CC: Greg Hudson , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: > On Thu, 3 Jul 2003, Alexey Melnikov wrote: > > > Ok people. I am afraid we are starting a religious war at this point and > > this is not going to do us any good. > > I agree. > > > So, how about making some constructive suggestions. How about the following: > > 1). libraries MUST NOT specify callbacks when calling > > sasl_client_init/sasl_server_init. > > Global callbacks are thus deprecated. > > > > 2). a new function is added to set getopt callback. An application that > > doesn't care about getopt, will not call this function. If this callback > > is not set, the SASL library will use reasonable defaults or get the > > required information from own config file/environment/registry/whatever. > > > > 3). one of the getopt options is a plugin directory. If the application doesn't > > care, its getopt callback will fail to return the value for this option. The > > SASL library will choose a reasonable default in this case. If the SASL library > > doesn't support plugins, it will not care about this option. > > This is worse than the global callbacks scenario with libraries forbidden > from setting global callbaks, since in this situation a libary can call > the magic new function to set the getopt() callback. IMHO, it is not different. You can't prevent libraries or applications from doing stupid things, you can only advise them how to avoid problems. > I don't see how this is better than allowing a getopt() callback to be set > by the application, but not by libraries in the call to sasl_xxx_init(). Would you rather allow getopt (and only getopt) to be set by the application when calling a sasl_xxx_init() and a library using SASL always pass NULL as callbacks? > Even if we forbid libraries from calling this new function, the situation > is worse than allowing applications to set a getopt callback in their call > to sasl_xxx_init(), as it requires changes from current practice. > > > I believe this is how it works now anyway (except for new function for setting > > getopt). > > Not quite true, this requires standardizing the name of an option, as > well. I meant in Cyrus SASL library, not the document. Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63MiAqt026210 for ; Thu, 3 Jul 2003 15:44:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63MiAs4026209 for ietf-sasl-bks; Thu, 3 Jul 2003 15:44:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63Mi8qt026203 for ; Thu, 3 Jul 2003 15:44:09 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h63MiAuO031643; Thu, 3 Jul 2003 18:44:10 -0400 Date: Thu, 3 Jul 2003 18:44:10 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: Greg Hudson , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library In-Reply-To: <3F04ADD2.31E16D8B@isode.com> Message-ID: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 3 Jul 2003, Alexey Melnikov wrote: > Ok people. I am afraid we are starting a religious war at this point and > this is not going to do us any good. I agree. > So, how about making some constructive suggestions. How about the following: > 1). libraries MUST NOT specify callbacks when calling > sasl_client_init/sasl_server_init. > Global callbacks are thus deprecated. > > 2). a new function is added to set getopt callback. An application that > doesn't care about getopt, will not call this function. If this callback > is not set, the SASL library will use reasonable defaults or get the > required information from own config file/environment/registry/whatever. > > 3). one of the getopt options is a plugin directory. If the application doesn't > care, its getopt callback will fail to return the value for this option. The > SASL library will choose a reasonable default in this case. If the SASL library > doesn't support plugins, it will not care about this option. This is worse than the global callbacks scenario with libraries forbidden from setting global callbaks, since in this situation a libary can call the magic new function to set the getopt() callback. I don't see how this is better than allowing a getopt() callback to be set by the application, but not by libraries in the call to sasl_xxx_init(). Even if we forbid libraries from calling this new function, the situation is worse than allowing applications to set a getopt callback in their call to sasl_xxx_init(), as it requires changes from current practice. > I believe this is how it works now anyway (except for new function for setting > getopt). Not quite true, this requires standardizing the name of an option, as well. -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.9/8.12.8) with ESMTP id h63Mh1qt026128 for ; Thu, 3 Jul 2003 15:43:01 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63Mh1jd026127 for ietf-sasl-bks; Thu, 3 Jul 2003 15:43:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63Mh0qt026122 for ; Thu, 3 Jul 2003 15:43:00 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h63Mh16i028898; Thu, 3 Jul 2003 18:43:01 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h63Mh0qM022391; Thu, 3 Jul 2003 18:43:01 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h63MgvFJ018404; Thu, 3 Jul 2003 18:42:58 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h63MgunK026152; Thu, 3 Jul 2003 18:42:56 -0400 Subject: Re: Using SASL C API from a library From: Greg Hudson To: Alexey Melnikov Cc: ietf-sasl@imc.org In-Reply-To: <3F04ADD2.31E16D8B@isode.com> References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> <3F04ADD2.31E16D8B@isode.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057272175.12524.444.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 03 Jul 2003 18:42:56 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-07-03 at 18:27, Alexey Melnikov wrote: > So, how about making some constructive suggestions. How about the following: > 1). libraries MUST NOT specify callbacks when calling > sasl_client_init/sasl_server_init. > Global callbacks are thus deprecated. You seem to leave open the question of whether applications are allowed to specify callbacks. Was that intentional? (As I've mentioned before, if applications are allowed to set global callbacks, then a library using SASL cannot guard against accidentally triggering the application global callbacks.) > 2). a new function is added to set getopt callback. An application that doesn't > care about getopt, will not call this function. Well, as everybody knows, my religion does not include such a device, but global state is generally not burdensome as long as it's (completely) optional. So I won't scream and yell about it. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63MTlqt025102 for ; Thu, 3 Jul 2003 15:29:47 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63MTlte025101 for ietf-sasl-bks; Thu, 3 Jul 2003 15:29:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63MTkqt025096 for ; Thu, 3 Jul 2003 15:29:46 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust9.tnt14.lnd4.gbr.da.uu.net [62.188.143.9]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h63MXFV08159; Thu, 3 Jul 2003 16:33:16 -0600 Message-ID: <3F04ADD2.31E16D8B@isode.com> Date: Thu, 03 Jul 2003 16:27:30 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg Hudson CC: Rob Siemborski , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greg Hudson wrote: > On Thu, 2003-07-03 at 09:51, Rob Siemborski wrote: > > Are you saying its better to have NO standard way to get configuration > > information into the library fromt he application? > > Absolutely. The vast majority of APIs contain no such mechanism, > because a library should be able to do its job without creating such a > mechanism. If for some reason the library needs configuration, it can > get it via its own configuration files, which it can find through > mechanisms not involving the calling code (fixed paths, environment > variables, the registry, etc.). I am afraid I disagree. Centralizing all configuration for an application in one place might be a good (and required) thing. > The only exception class tends to be gui toolkits, which usually want to > take over the command line by accepting and modifying argc and argv. > I'm ambivalent about this practice (it makes it harder to document the > command-line syntax of programs using the gui toolkit, but it's hard to > imagine doing without it given the variety of standard command-line > arguments affecting the toolkit), but it's not terribly onerous because > a GUI toolkit tends to dominate the scope and structure of an > application. Not so with a SASL library. > > > Thus, if I want an > > application to work with two types of libraries, I have to provide (in > > hard code) perhaps a callback for SASL_NONSTANARD_CB_PATHNAME and > > SASL_NONSTANDARD_CB_PATH_TO_PLUGINS just to work with two implementation? > > If we are talking about an application providing this information for > its own reasons, then it's already sunk; the SASL API says nothing about > plugin paths, you don't know what option name would be involved, and the > implementation might not even use plugins. (And of course, if the > application is providing such information for its own reasons, it > probably cares about the back-end plugin interface, which isn't > specified at all.) > > But, of course, the specifiers are not envisioning an application > providing this information for its own reasons; they are envisioning an > application blindly (no stigma here) passing along user configuration, > as reflected here: Ok people. I am afraid we are starting a religious war at this point and this is not going to do us any good. So, how about making some constructive suggestions. How about the following: 1). libraries MUST NOT specify callbacks when calling sasl_client_init/sasl_server_init. Global callbacks are thus deprecated. 2). a new function is added to set getopt callback. An application that doesn't care about getopt, will not call this function. If this callback is not set, the SASL library will use reasonable defaults or get the required information from own config file/environment/registry/whatever. 3). one of the getopt options is a plugin directory. If the application doesn't care, its getopt callback will fail to return the value for this option. The SASL library will choose a reasonable default in this case. If the SASL library doesn't support plugins, it will not care about this option. I believe this is how it works now anyway (except for new function for setting getopt). Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63IZ4qt013617 for ; Thu, 3 Jul 2003 11:35:04 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63IZ4mS013616 for ietf-sasl-bks; Thu, 3 Jul 2003 11:35:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63IZ3qt013611 for ; Thu, 3 Jul 2003 11:35:03 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h63IZ3uO023946; Thu, 3 Jul 2003 14:35:03 -0400 Date: Thu, 3 Jul 2003 14:35:02 -0400 (EDT) From: Rob Siemborski To: ietf-sasl@imc.org cc: kurt@OpenLDAP.org Subject: Re: I-D ACTION:draft-ietf-sasl-anon-02.txt In-Reply-To: <200307022034.QAA13327@ietf.org> Message-ID: References: <200307022034.QAA13327@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 Wed, 2 Jul 2003 Internet-Drafts@ietf.org wrote: > Title : The Anonymous SASL Mechanism > Author(s) : K. Zeilenga > Filename : draft-ietf-sasl-anon-02.txt >> ...not part of SASL itself. Newer profiles of SASL will include the client message with the AUTHENTICATE command itself so the extra round trip below (the server response with an empty "+ ") can be eliminated. << Seems to indicate a requirement on new SASL profiles, which is outside of the scope of the document. However, it is reasonable to add some clarification that the extra round trip is an artifact of the IMAP profile. How about something more like: ...not part of SASL itself. Additionally, protocols with SASL profiles permitting an initial client response will be able to avoid the extra round trip below (the server response with an empty "+ "). -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.9/8.12.8) with ESMTP id h63HPWqt008221 for ; Thu, 3 Jul 2003 10:25:32 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63HPW45008220 for ietf-sasl-bks; Thu, 3 Jul 2003 10:25:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63HPVqt008212 for ; Thu, 3 Jul 2003 10:25:31 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h63HPR2A004231; Thu, 3 Jul 2003 13:25:30 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h63HKREk026630; Thu, 3 Jul 2003 13:20:28 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h63HKRFJ009668; Thu, 3 Jul 2003 13:20:27 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h63HKQ57025753; Thu, 3 Jul 2003 13:20:26 -0400 Subject: Re: Using SASL C API from a library From: Greg Hudson To: Rob Siemborski Cc: ietf-sasl@imc.org In-Reply-To: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057252825.12524.435.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 03 Jul 2003 13:20:26 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-07-03 at 13:15, Rob Siemborski wrote: > However, in your scenario all the applications running on a system need to > share the same global configuration with no possibility of making > application-specific changes. Which really isn't acceptable. Why not? There is no application-specific configuration for krb5, or for the resolver, or for a host of other libraries. (You can, of course, hack it up using environment variables and alternate config files, but people rarely seem to.) If you actually can come up with a practical reason to have application-specific configuration for a SASL library (a concept which doesn't make a lot of sense when SASL is being driven from another library), then it is *still* better to handle this from a SASL-specific configuration file, using options keyed off the application name, because then it's possible to write documentation and GUI tools which understand everything about the config file, unlike in your scheme. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63HFXqt007884 for ; Thu, 3 Jul 2003 10:15:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63HFXIp007883 for ietf-sasl-bks; Thu, 3 Jul 2003 10:15:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63HFWqt007877 for ; Thu, 3 Jul 2003 10:15:32 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h63HFWuO019390; Thu, 3 Jul 2003 13:15:32 -0400 Date: Thu, 3 Jul 2003 13:15:31 -0400 (EDT) From: Rob Siemborski To: Greg Hudson cc: ietf-sasl@imc.org Subject: Re: Using SASL C API from a library In-Reply-To: <1057251866.12524.430.camel@error-messages.mit.edu> Message-ID: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> <1057251866.12524.430.camel@error-messages.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 Thu, 3 Jul 2003, Greg Hudson wrote: > And if I want to change where (say) Cyrus SASL looks for its plugins, > why would I want to have to do that for every application which uses > Cyrus SASL, instead of doing it in one place? Nothing prevents the library from having defaults, or looking at environment variables, or reading from /dev/random to gain the information otherwise provided by getopt in other ways. However, in your scenario all the applications running on a system need to share the same global configuration with no possibility of making application-specific changes. Which really isn't acceptable. -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.9/8.12.8) with ESMTP id h63H4Vqt006936 for ; Thu, 3 Jul 2003 10:04:31 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63H4VqB006935 for ietf-sasl-bks; Thu, 3 Jul 2003 10:04:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63H4Uqt006929 for ; Thu, 3 Jul 2003 10:04:31 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h63H4TmK015407; Thu, 3 Jul 2003 13:04:29 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h63H4SEk025075; Thu, 3 Jul 2003 13:04:28 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h63H4SFJ009148; Thu, 3 Jul 2003 13:04:28 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h63H4RcJ025661; Thu, 3 Jul 2003 13:04:27 -0400 Subject: Re: Using SASL C API from a library From: Greg Hudson To: Rob Siemborski Cc: ietf-sasl@imc.org In-Reply-To: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057251866.12524.430.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 03 Jul 2003 13:04:27 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-07-03 at 09:51, Rob Siemborski wrote: > Are you saying its better to have NO standard way to get configuration > information into the library fromt he application? Absolutely. The vast majority of APIs contain no such mechanism, because a library should be able to do its job without creating such a mechanism. If for some reason the library needs configuration, it can get it via its own configuration files, which it can find through mechanisms not involving the calling code (fixed paths, environment variables, the registry, etc.). The only exception class tends to be gui toolkits, which usually want to take over the command line by accepting and modifying argc and argv. I'm ambivalent about this practice (it makes it harder to document the command-line syntax of programs using the gui toolkit, but it's hard to imagine doing without it given the variety of standard command-line arguments affecting the toolkit), but it's not terribly onerous because a GUI toolkit tends to dominate the scope and structure of an application. Not so with a SASL library. > Thus, if I want an > application to work with two types of libraries, I have to provide (in > hard code) perhaps a callback for SASL_NONSTANARD_CB_PATHNAME and > SASL_NONSTANDARD_CB_PATH_TO_PLUGINS just to work with two implementation? If we are talking about an application providing this information for its own reasons, then it's already sunk; the SASL API says nothing about plugin paths, you don't know what option name would be involved, and the implementation might not even use plugins. (And of course, if the application is providing such information for its own reasons, it probably cares about the back-end plugin interface, which isn't specified at all.) But, of course, the specifiers are not envisioning an application providing this information for its own reasons; they are envisioning an application blindly (no stigma here) passing along user configuration, as reflected here: > The getopt callback supplys a standard way to get this information from > the application. Since presumably the application is looking up this > information in its own config files, the user can read the documentation > for their SASL implementation and decide if they need to set the SASL > option "pathname" or "path_to_plugins". This can be done without needing > to change the code to the application. We're going around in circles on this point. I'll skip the part where I argue against this idea at the end of and go to the part where you respond in with (among discussions of fixed paths versus other ways of finding a config file, which we've also talked about at length): And being able to combine SASL options with application options in one place is a usability improvement. which is another puzzling argument. Most discussion of usability revolves around GUI interfaces, and it is impossible to create a non-degenerate GUI configuration interface for options you know nothing about. The best you can do is provide a registry-like interface where the user can manipulate key-value pairs, which is only one step away from editing text files. But even if we're talking about usability among the tiny (percentagewise) population of users who are comfortable editing configuration files, I don't see the benefit. Why would I want to have a single configuration whose meaning is split over two or more different pieces of documentation? Wouldn't I like my configuration files to have nicely commented templates? (That would be logistically difficult for configuration files which span abstraction barriers like you envision.) And if I want to change where (say) Cyrus SASL looks for its plugins, why would I want to have to do that for every application which uses Cyrus SASL, instead of doing it in one place? Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63Flwqt000231 for ; Thu, 3 Jul 2003 08:47:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63Flw5N000230 for ietf-sasl-bks; Thu, 3 Jul 2003 08:47:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63Floqt000223 for ; Thu, 3 Jul 2003 08:47:57 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust128.tnt24.lnd4.gbr.da.uu.net [62.188.151.128]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h63FkmV04797; Thu, 3 Jul 2003 09:46:51 -0600 Message-ID: <3F043077.BD141F4F@isode.com> Date: Thu, 03 Jul 2003 07:32:39 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Josefsson CC: ietf-sasl@imc.org Subject: Re: Comments on the SASL C API References: <3F037AF4.7919F21C@isode.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon Josefsson wrote: > Alexey Melnikov writes: > > > I've added some clarification about multiple SASL tokens in sasl_decode as > > described by Larry. > > Thank you, and also to Greg and Larry who provided insight. The > problem had a simple solution, but it wasn't really obvious [to me], > so additional text would not hurt. Perhaps it can even be useful to > application writers, so they know sasl_decode() could return data that > is the concatenation of output from more than one call to > sasl_encode(). It appears that this could affect the choice of buffer > sizes. sasl_decode allocates or returns own buffer, so the caller shouldn't worry about buffer sizes. Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63DpbFK058744 for ; Thu, 3 Jul 2003 06:51:37 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63Dpb9q058743 for ietf-sasl-bks; Thu, 3 Jul 2003 06:51:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63DpaFK058738 for ; Thu, 3 Jul 2003 06:51:36 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h63DpZuO006317; Thu, 3 Jul 2003 09:51:35 -0400 Date: Thu, 3 Jul 2003 09:51:35 -0400 (EDT) From: Rob Siemborski To: Greg Hudson cc: Alexey Melnikov , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library In-Reply-To: <1057197903.12524.401.camel@error-messages.mit.edu> Message-ID: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> <1057197903.12524.401.camel@error-messages.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 Wed, 2 Jul 2003, Greg Hudson wrote: > But let's say I'm wrong, and there really is some good reason why the > calling code should be helping out. And let's also say that this reason > isn't good enough to make the plugin directory part of the standard SASL > C API. What value is there in half-standardizing the interface through > which the library gets this information? If some application needs this > non-standard functionality and therefore can only use (let's say) the > Cyrus implementation, then the Cyrus implementation can add its own > non-standard function to specify the plugin directory. Are you saying its better to have NO standard way to get configuration information into the library fromt he application? Thus, if I want an application to work with two types of libraries, I have to provide (in hard code) perhaps a callback for SASL_NONSTANARD_CB_PATHNAME and SASL_NONSTANDARD_CB_PATH_TO_PLUGINS just to work with two implementation? Worse: what if these two implementations define the same values for these two callbacks! The getopt callback supplys a standard way to get this information from the application. Since presumably the application is looking up this information in its own config files, the user can read the documentation for their SASL implementation and decide if they need to set the SASL option "pathname" or "path_to_plugins". This can be done without needing to change the code to the application. -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.9/8.12.8) with ESMTP id h633U9FK000923 for ; Wed, 2 Jul 2003 20:30:09 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h633U8Y1000922 for ietf-sasl-bks; Wed, 2 Jul 2003 20:30:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h633U7FK000917 for ; Wed, 2 Jul 2003 20:30:07 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h633U6ST018367 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 3 Jul 2003 05:30:07 +0200 To: Alexey Melnikov Cc: ietf-sasl@imc.org Subject: Re: Comments on the SASL C API References: <3F037AF4.7919F21C@isode.com> From: Simon Josefsson X-Payment: hashcash 1.2 0:030703:Alexey.Melnikov@isode.com:eaeec8eca266056f X-Hashcash: 0:030703:Alexey.Melnikov@isode.com:eaeec8eca266056f X-Payment: hashcash 1.2 0:030703:ietf-sasl@imc.org:b8615009abdb22a5 X-Hashcash: 0:030703:ietf-sasl@imc.org:b8615009abdb22a5 Date: Thu, 03 Jul 2003 05:30:06 +0200 In-Reply-To: <3F037AF4.7919F21C@isode.com> (Alexey Melnikov's message of "Wed, 02 Jul 2003 18:38:12 -0600") 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 X-Spam-Status: No, hits=-29.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > I've added some clarification about multiple SASL tokens in sasl_decode as > described by Larry. Thank you, and also to Greg and Larry who provided insight. The problem had a simple solution, but it wasn't really obvious [to me], so additional text would not hurt. Perhaps it can even be useful to application writers, so they know sasl_decode() could return data that is the concatenation of output from more than one call to sasl_encode(). It appears that this could affect the choice of buffer sizes. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63259FK098063 for ; Wed, 2 Jul 2003 19:05:09 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h632593O098062 for ietf-sasl-bks; Wed, 2 Jul 2003 19:05:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63257FK098057 for ; Wed, 2 Jul 2003 19:05:08 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h63257QU012768; Wed, 2 Jul 2003 22:05:07 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h63256pP012527; Wed, 2 Jul 2003 22:05:07 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h63256FJ021029; Wed, 2 Jul 2003 22:05:06 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h63254l8025028; Wed, 2 Jul 2003 22:05:04 -0400 Subject: Re: Using SASL C API from a library From: Greg Hudson To: Alexey Melnikov Cc: ietf-sasl@imc.org In-Reply-To: <3F037BD6.AC4E6681@isode.com> References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> <3F037BD6.AC4E6681@isode.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057197903.12524.401.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 02 Jul 2003 22:05:04 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 2003-07-02 at 20:41, Alexey Melnikov wrote: > > Options required for a SASL library itself should be nailed down by the > > spec or not subject to configuration by the caller. (The plugin dir, > > for instance, should be found in a fixed location or via an environment > > variable; there's no reason for SASL to introduce a completely new > > override mechanism.) > > Oh, please. What if my application wants to use a fixes path, but not the one > hardcoded in the SASL library? > > Plus hardcoded paths don't work on certain OSes (e.g. Windows). Why would you ever write an application which cares, more than any other application, where a SASL library looks for its plugin directory? Every caller of the SASL library should be in the same position here. Which means the library needs to be able to find its plugins without help from the calling code. Whether that means a fixed path, an environment variable, the registry, or whatever else is up to the library, but asking the calling code to provide that information is of no help. But let's say I'm wrong, and there really is some good reason why the calling code should be helping out. And let's also say that this reason isn't good enough to make the plugin directory part of the standard SASL C API. What value is there in half-standardizing the interface through which the library gets this information? If some application needs this non-standard functionality and therefore can only use (let's say) the Cyrus implementation, then the Cyrus implementation can add its own non-standard function to specify the plugin directory. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h631rYFK097014 for ; Wed, 2 Jul 2003 18:53:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h631rYnZ097013 for ietf-sasl-bks; Wed, 2 Jul 2003 18:53:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h631rYFK097008 for ; Wed, 2 Jul 2003 18:53:34 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust22.tnt101.lnd4.gbr.da.uu.net [213.116.50.22]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h631vAV31120; Wed, 2 Jul 2003 19:57:11 -0600 Message-ID: <3F037D21.D883D566@isode.com> Date: Wed, 02 Jul 2003 18:47:29 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Siemborski CC: ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: > > Since people have grown silent on the topic, I'll note that no excuse > > has been given for the global callbacks structure, and no answer has > > been given to my argument that library calls to the SASL C API could > > accidentally trigger invocations of the application's global callbacks > > no matter what the library does to guard against this possibility. If > > transition for users of Cyrus SASL is the only concern, then the API > > spec can preserve the parameter as a dummy and mandate that all callers > > must pass NULL, as has been done in Unix with gettimeofday() and the > > timezone parameter. > > Unless I am misremembering, this is basically what we discussed in San > Francisco (I thought I had mentioned that). Yes, this is in my notes. More specifically: 1). Init problem: deprecatate global callbacks. If global callbacks are provided multiple times, this is implementation dependent. 2). Make appname setprop/getprop appname must be NULL in sasl_server_init, if it is called from a library. > Note that this is difficult for situations such as the getopt callback, > where path information to loadable modules (or similar information that is > requried for the library to initialize) may need to be obtained. In this > case (since it is part of the one-time library startup) the application > would need to supply a getopt callback. Since its one-time startup state, > your library couldn't change it if it wanted to. So, where this discussion leaves us? Should I change the document to say that global callbacks must be NULL, except for maybe the getopt callback? Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h631rOFK097002 for ; Wed, 2 Jul 2003 18:53:24 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h631rO8j097001 for ietf-sasl-bks; Wed, 2 Jul 2003 18:53:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h631rOFK096996 for ; Wed, 2 Jul 2003 18:53:24 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust22.tnt101.lnd4.gbr.da.uu.net [213.116.50.22]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h631utV31115; Wed, 2 Jul 2003 19:56:56 -0600 Message-ID: <3F037BD6.AC4E6681@isode.com> Date: Wed, 02 Jul 2003 18:41:59 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg Hudson CC: Rob Siemborski , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> <1057073245.12524.334.camel@error-messages.mit.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greg Hudson wrote: > > Sure, the library can also just access a configuration file to get the > > information it needs, but then how does the user supply the path the the > > configuration file? I'm quite certain that having a fixed path to a > > configuration file isn't what users are looking for. > > I believe this is argument from fantasy. I don't think there's any > back-end mechanism library which asks for this kind of information from > the calling code. They all uses fixed paths, possibly overridden by > environment variables which the calling code is not expected to tamper > with. > > And being able to combine SASL options with application options in one > > place is a usability improvement. > > Options required for a SASL library itself should be nailed down by the > spec or not subject to configuration by the caller. (The plugin dir, > for instance, should be found in a fixed location or via an environment > variable; there's no reason for SASL to introduce a completely new > override mechanism.) Oh, please. What if my application wants to use a fixes path, but not the one hardcoded in the SASL library? Plus hardcoded paths don't work on certain OSes (e.g. Windows). Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h631rAFK096986 for ; Wed, 2 Jul 2003 18:53:10 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h631rAKH096985 for ietf-sasl-bks; Wed, 2 Jul 2003 18:53:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h631r9FK096980 for ; Wed, 2 Jul 2003 18:53:09 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust22.tnt101.lnd4.gbr.da.uu.net [213.116.50.22]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h631udV31109; Wed, 2 Jul 2003 19:56:41 -0600 Message-ID: <3F037AF4.7919F21C@isode.com> Date: Wed, 02 Jul 2003 18:38:12 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Josefsson CC: ietf-sasl@imc.org Subject: Re: Comments on the SASL C API References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon Josefsson wrote: > ... I've added some clarification about multiple SASL tokens in sasl_decode as described by Larry. > Extension: > Here is a writeup on an idea I have received. It might cause some > complications and likely needs more pondering. However, if the > rationale for adding this makes sense to you, I'd appreciate if you > spent the time incorporating the functions. If you are familiar with > the GSS-API, compare this to the gss_export_sec_context and > gss_import_sec_context functions that were added to GSS-API version 2 > (see RFC 2744). I like the idea and had though about something similar myself. The question is if this belong to the base SASL API document or should this be an extension. I would like to hear what other people think about adding this. > 5.2. Exporting and importing security layer state > > Some application environments wishes to separate the initial and > short authentication step from the potentially long lived > application step, where the application uses sasl_encode() and > sasl_decode() to transfer application data. This separation may > be between processes (separation across hosts is more > complicated, as the security layer state is often dependent on > the host address, but still conceivable). The reason for such > separation may be to guarantee that long-term secrets (e.g., > passwords) cannot be recovered by compromising the application > that handles existing session. > > The functions defined in this section allows the application to > export the security layer state associated with a session as an > opaque character string, and later import the opaque character > string. The opaque state typically contains an encryption key, > initialization vectors, what encryption algorithm to use, packet > number etc. > > 5.2.1. sasl_export_security_layer_state function > > Arguments: > sasl_conn_t *conn, > const char **state, > unsigned int *statelen > > Results: > SASL_OK -- Success > SASL_NOTDONE -- Security layer negotiation not finished > > This function exports the security layer state required to > implement the sasl_encode() and sasl_decode() functions after > the state has been imported. The security layer state is an > opaque data string. The state and statelen are filled in with > the opaque state data and its length respectively. If the > security layer negotiation has not finished, SASL_NOTDONE is > returned. After calling this function, the application should > treat the SASL session as concluded and call sasl_dispose(). In > particular, the application MUST NOT call sasl_encode() or > sasl_decode() [XXX sasl_dencode should simply return a error > code when it happens]. The state data is only valid until a > call to sasl_dispose(), and should be copied before calling > sasl_dipose() if necessary. > > 5.2.2. sasl_import_security_layer_state function > > Arguments: > const char *state, > unsigned int statelen > sasl_conn_t **conn, > > Results: > SASL_OK -- Success > SASL_BADPARAM -- Invalid parameter supplied > > This function create a SASL session, for use with sasl_encode(), > sasl_decode() and sasl_dispose() only, from the given security > layer state. The security layer state is an opaque data string, > as returned from sasl_export_security_layer_state(). Cheers, Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KZjFK082695 for ; Wed, 2 Jul 2003 13:35:45 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62KZj6g082694 for ietf-sasl-bks; Wed, 2 Jul 2003 13:35:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KYBFK082612 for ; Wed, 2 Jul 2003 13:34:15 -0700 (PDT) (envelope-from nsyracus@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 QAA13309; Wed, 2 Jul 2003 16:34:07 -0400 (EDT) Message-Id: <200307022034.QAA13309@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-saslprep-03.txt Date: Wed, 02 Jul 2003 16:34:06 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : SASLprep: Stringprep profile for user names and passwords Author(s) : K. Zeilenga Filename : draft-ietf-sasl-saslprep-03.txt Pages : 6 Date : 2003-7-2 This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the 'SASLprep' 'stringprep' profile to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging user names and/or passwords. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-03.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-saslprep-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-saslprep-03.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-7-2161947.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-saslprep-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-saslprep-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161947.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KYqFK082655 for ; Wed, 2 Jul 2003 13:34:52 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62KYqUx082654 for ietf-sasl-bks; Wed, 2 Jul 2003 13:34:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KYFFK082613 for ; Wed, 2 Jul 2003 13:34:28 -0700 (PDT) (envelope-from nsyracus@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 QAA13327; Wed, 2 Jul 2003 16:34:12 -0400 (EDT) Message-Id: <200307022034.QAA13327@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-anon-02.txt Date: Wed, 02 Jul 2003 16:34:12 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The Anonymous SASL Mechanism Author(s) : K. Zeilenga Filename : draft-ietf-sasl-anon-02.txt Pages : 9 Date : 2003-7-2 It is common practice on the Internet to permit anonymous access to various services. Traditionally, this has been done with a plain text password mechanism using 'anonymous' as the user name and optional trace information, such as an email address, as the password. As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the Simple Authentication and Security Layer (SASL) framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-anon-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-anon-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-anon-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2162000.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-anon-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-anon-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2162000.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KYkFK082645 for ; Wed, 2 Jul 2003 13:34:46 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62KYkVA082644 for ietf-sasl-bks; Wed, 2 Jul 2003 13:34:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KYOFK082617 for ; Wed, 2 Jul 2003 13:34:30 -0700 (PDT) (envelope-from nsyracus@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 QAA13350; Wed, 2 Jul 2003 16:34:17 -0400 (EDT) Message-Id: <200307022034.QAA13350@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-plain-02.txt Date: Wed, 02 Jul 2003 16:34:16 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : The Plain SASL Mechanism Author(s) : K. Zeilenga Filename : draft-ietf-sasl-plain-02.txt Pages : 8 Date : 2003-7-2 This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols which lack a simple password authentication command. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-plain-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-plain-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-plain-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2162011.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-plain-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-plain-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2162011.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62GadFK068828 for ; Wed, 2 Jul 2003 09:36:39 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62GadEW068827 for ietf-sasl-bks; Wed, 2 Jul 2003 09:36:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62GacFK068822 for ; Wed, 2 Jul 2003 09:36:38 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 09646151582; Wed, 2 Jul 2003 12:36:25 -0400 (EDT) To: ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> From: Sam Hartman Date: Wed, 02 Jul 2003 12:36:25 -0400 In-Reply-To: (Rob Siemborski's message of "Mon, 30 Jun 2003 14:50:44 -0400 (EDT)") 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: >>>>> "Rob" == Rob Siemborski writes: Rob> On Sun, 29 Jun 2003, Greg Hudson wrote: >> It seems like a bizarre argument, especially when Unix systems >> converged on the POSIX threads API years and years ago. Rob> Solaris has a non-pthreads threading API. There's no reason Rob> the SASL C API should dictate what threading API to use. It's my understanding that at least in recent Solaris versions, the locks between this API and the pthreads API are compatible. Please correct me if I'm wrong. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61FRTFK060498 for ; Tue, 1 Jul 2003 08:27:29 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61FRTD9060497 for ietf-sasl-bks; Tue, 1 Jul 2003 08:27:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61FRSFK060489 for ; Tue, 1 Jul 2003 08:27:28 -0700 (PDT) (envelope-from ghudson@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h61FRS9W001128; Tue, 1 Jul 2003 11:27:28 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h61FRRjO013920; Tue, 1 Jul 2003 11:27:27 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h61FRRU8006774; Tue, 1 Jul 2003 11:27:27 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h61FRQwU023364; Tue, 1 Jul 2003 11:27:26 -0400 Subject: Re: Using SASL C API from a library From: Greg Hudson To: Rob Siemborski Cc: ietf-sasl@imc.org In-Reply-To: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057073245.12524.334.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 01 Jul 2003 11:27:26 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2003-07-01 at 10:12, Rob Siemborski wrote: > > So, unless you can demonstrate a present practical issue, I don't think > > this argument is even vaguely compelling. > The good news here is that most of these are (or can be made to be) > connection-context specific. Ones that potentially need to be supported > by a global getopt callback really significantly fewer. Certainly it should be possible for krb5, since krb5 does not use global state. (It also does not allow the caller to pass a path to find krb5.conf.) > Sure, the library can also just access a configuration file to get the > information it needs, but then how does the user supply the path the the > configuration file? I'm quite certain that having a fixed path to a > configuration file isn't what users are looking for. I believe this is argument from fantasy. I don't think there's any back-end mechanism library which asks for this kind of information from the calling code. They all uses fixed paths, possibly overridden by environment variables which the calling code is not expected to tamper with. > And being able to combine SASL options with application options in one > place is a usability improvement. Options required for a SASL library itself should be nailed down by the spec or not subject to configuration by the caller. (The plugin dir, for instance, should be found in a fixed location or via an environment variable; there's no reason for SASL to introduce a completely new override mechanism.) > Implementations of the SASL API will require configuration options to > function properly, we shouldn't deny them a reasonable way to get that > information in a standard way, even if the information itself is > implementation dependent. Once again, you've made an argument which (I believe) no other standardized API makes, and provided no specific examples to back it up. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61ECsFK055913 for ; Tue, 1 Jul 2003 07:12:54 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61ECsgC055912 for ietf-sasl-bks; Tue, 1 Jul 2003 07:12:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61ECqFK055906 for ; Tue, 1 Jul 2003 07:12:52 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from BBOARD.andrew.cmu.edu (BBOARD.andrew.cmu.edu [128.2.10.89]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h61ECquO006725; Tue, 1 Jul 2003 10:12:52 -0400 Date: Tue, 1 Jul 2003 10:12:53 -0400 (EDT) From: Rob Siemborski To: Greg Hudson cc: ietf-sasl@imc.org Subject: Re: Using SASL C API from a library In-Reply-To: <1057032466.12524.317.camel@error-messages.mit.edu> Message-ID: References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <1057032466.12524.317.camel@error-messages.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 Tue, 1 Jul 2003, Greg Hudson wrote: > > Unless I am misremembering, this is basically what we discussed in San > > Francisco (I thought I had mentioned that). > > (The minutes do not appear to document any discussion of the SASL C API, > incidentally.) Since its not a charter item, it wasn't discussed in the formal WG meeting. I think Alexey has notes from when a few of us sat around discussing it though. > Previously, you said "it can be solved by not using global callbacks > except in the outermost application," which is very different from "not > using global callbacks at all." > > > Note that this is difficult for situations such as the getopt callback > > where path information to loadable modules (or similar information that is > > requried for the library to initialize) may need to be obtained. > > There is really no limit to the number of awful things you could justify > putting into the API if you want to satisfy every possible foible of a > back-end library. [snip] You don't need to satisfy every possible one, but let's at least try to anticipate reasonable desires of the implementors. > So, unless you can demonstrate a present practical issue, I don't think > this argument is even vaguely compelling. Kerberos mechanisms need a path to a srvtab or keytab. Perhaps shared secret mechanisms need a path to a database of shared secrets. Perhaps one of the worse examples (though one of the most useful) is a list of mechanisms to limit what the library advertises. The good news here is that most of these are (or can be made to be) connection-context specific. Ones that potentially need to be supported by a global getopt callback really significantly fewer. > Franky, the getopt callback is a great big hole in the spec for > unspecified behavior (both mechanism-specific and > implementation-specific), since there is no standardization of what the > options mean. Presumably the idea is that you would provide the answers > from a configuration file or from command-line options, giving a sort of > direct communications channel between the user and the SASL library or > specific mechanism. That may sound attractive to implementors, but it's > a totally unacceptable idea, because it's impossible to document such a > config file or command-line syntax without knowing the intimate (and > version-specific) details of your SASL implementation, and because it's > impossible to provide reasonable answers in a situation where a config > file or command line doesn't make sense. The application doesn't have to understand the options its handing to the library, only the user does. And the user can have access to implementation-specific information about the library. Sure, the library can also just access a configuration file to get the information it needs, but then how does the user supply the path the the configuration file? I'm quite certain that having a fixed path to a configuration file isn't what users are looking for. And being able to combine SASL options with application options in one place is a usability improvement. Implementations of the SASL API will require configuration options to function properly, we shouldn't deny them a reasonable way to get that information in a standard way, even if the information itself is implementation dependent. -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.9/8.12.8) with ESMTP id h61E26FK055184 for ; Tue, 1 Jul 2003 07:02:06 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61E240x055183 for ietf-sasl-bks; Tue, 1 Jul 2003 07:02:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61E23FK055174 for ; Tue, 1 Jul 2003 07:02:03 -0700 (PDT) (envelope-from leg@andrew.cmu.edu) Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.12.9/8.12.6) with ESMTP id h61E1sXM006527; Tue, 1 Jul 2003 07:01:54 -0700 Received: from mirapoint.corp.google.com (IDENT:mirapoint@mirapoint.corp.google.com [10.32.0.80]) by moma.corp.google.com (8.12.9/8.12.3) with ESMTP id h61E1sff029572; Tue, 1 Jul 2003 07:01:54 -0700 Received: from andrew.cmu.edu (dunbar.corp.google.com [10.2.2.110]) by mirapoint.corp.google.com (Mirapoint Messaging Server MOS 3.3.5-GR) with ESMTP id ABT15494 (AUTH leg); Tue, 1 Jul 2003 07:01:53 -0700 (PDT) Message-ID: <3F019450.8020808@andrew.cmu.edu> Date: Tue, 01 Jul 2003 10:01:52 -0400 From: Larry Greenfield User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Guenther CC: Rob Siemborski , Greg Hudson , ietf-sasl@imc.org Subject: Re: Using SASL C API from a library References: <5.2.0.9.0.20030629085944.01ba1408@127.0.0.1> <200306292310.h5TNApik012109@smtp6.andrew.cmu.edu> <1056929355.12524.175.camel@error-messages.mit.edu> <1056999906.12524.250.camel@error-messages.mit.edu> <200307010007.h61077uN021179@smtp5.andrew.cmu.edu> <1057019499.12524.277.camel@error-messages.mit.edu> <200307010435.h614Zgf12987@katroo.Sendmail.COM> In-Reply-To: <200307010435.h614Zgf12987@katroo.Sendmail.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: >Rob Siemborski writes: >... > > >>This works, until an application is running using an incompatible >>threading API (see Larry's answer to my earlier question). >> >> >I knew I should have replied to Larry's answer. I find his example >unconvincing. He has suggested that there may exist a cooperative >threading library running on a system that has a system level threading >implementation and that intercepts blocking I/O calls (i.e., supplies >symbols like connect(), read(), etc) such that it intercepts the calls >of unmodified libraries, but that *doesn't* intercept calls to the >system's threading primitives. (If that's not what you're suggesting, >Larry, please correct me.) > This appears to be an accurate description of the GNU Pth library using the "hard system call mapping". (I base this off of the documentation and not first hand experience.) Pth is a popular and frequently used threading library. Larry Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61BNrFK046736 for ; Tue, 1 Jul 2003 04:23:53 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61BNrNH046735 for ietf-sasl-bks; Tue, 1 Jul 2003 04:23:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61BNqFK046730 for ; Tue, 1 Jul 2003 04:23:53 -0700 (PDT) (envelope-from nsyracus@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 HAA07340; Tue, 1 Jul 2003 07:23:50 -0400 (EDT) Message-Id: <200307011123.HAA07340@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-rfc2831bis-02.txt Date: Tue, 01 Jul 2003 07:23:50 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Using Digest Authentication as a SASL Mechanism Author(s) : P. Leach, C. Newman, A. Melnikov Filename : draft-ietf-sasl-rfc2831bis-02.txt Pages : 39 Date : 2003-6-30 This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2831bis-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2831bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-30151553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2831bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-30151553.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61BNnFK046726 for ; Tue, 1 Jul 2003 04:23:49 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61BNnDl046725 for ietf-sasl-bks; Tue, 1 Jul 2003 04:23:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61BNmFK046720 for ; Tue, 1 Jul 2003 04:23:48 -0700 (PDT) (envelope-from nsyracus@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 HAA07324; Tue, 1 Jul 2003 07:23:45 -0400 (EDT) Message-Id: <200307011123.HAA07324@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-01.txt Date: Tue, 01 Jul 2003 07:23:45 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-01.txt Pages : 18 Date : 2003-6-30 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-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-rfc2222bis-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-rfc2222bis-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-6-30151543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-30151543.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61BMYFK046652 for ; Tue, 1 Jul 2003 04:22:34 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61BMY7W046651 for ietf-sasl-bks; Tue, 1 Jul 2003 04:22:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61BMWFK046646 for ; Tue, 1 Jul 2003 04:22:32 -0700 (PDT) (envelope-from nsyracus@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 HAA06867; Tue, 1 Jul 2003 07:22:29 -0400 (EDT) Message-Id: <200307011122.HAA06867@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-sasl@imc.org, ietf-http-wg@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-nystrom-http-sasl-07.txt Date: Tue, 01 Jul 2003 07:22:28 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SASL in HTTP/1.1 Author(s) : M. Nystrom, A. Melnikov Filename : draft-nystrom-http-sasl-07.txt Pages : 33 Date : 2003-6-30 This memo suggest the use of SASL [RFC2222] as a framework to enable the use of strong authentication mechanisms in http/1.1 [RFC2616], and defines one approach to accomplish this. Please send comments on this document to the relevant mailing lists, e.g. ietf-sasl@imc.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-07.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-nystrom-http-sasl-07.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-nystrom-http-sasl-07.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-6-30151300.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nystrom-http-sasl-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-nystrom-http-sasl-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-30151300.I-D@ietf.org> --OtherAccess-- --NextPart--