FYI, Wildfire 2.6.0 to be released next week will include a fix for this problem. Now it is possible for clients to send an empty SASL PLAIN <auth> stanza and the server will send a challenge to the client. For those of you that need to get this fix sooner, you can download the next nightly build from http://www.jivesoftware.org/nightly.jsp. Feel free to contact me if you need any help upgrading your installation to use the nightly build version.
Thanks, -- Gato "Peter Saint-Andre" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Forwarded with permission... /psa -------- Original Message -------- Subject: Re: [Fwd: Re: [jdev] Re: tls + plain sasl not working] Date: Sun, 26 Mar 2006 15:12:28 -0800 From: Kurt D. Zeilenga <[EMAIL PROTECTED]> To: Peter Saint-Andre <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] References: <[EMAIL PROTECTED]> Sorry for the delayed response, been busy at (and recovering from) IETF#65. At 09:09 AM 3/22/2006, Peter Saint-Andre wrote: > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA1 > > > >Hello SASL gurus, > > > >A question has some up on the Jabber developer mailing list that perhaps > >could be clarified in rfc2222bis. Please read on for details... > > > >Thanks! > > > >Peter > > > >- -------- Original Message -------- > >Subject: Re: [jdev] Re: tls + plain sasl not working > >Date: Wed, 22 Mar 2006 10:05:52 -0700 > >From: Peter Saint-Andre <[EMAIL PROTECTED]> > >Reply-To: Jabber software development list <[email protected]> > >To: Jabber software development list <[email protected]> > >References: > ><[EMAIL PROTECTED]> > ><[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > > > >Ralph Meijer wrote: >> >> On Wed, Mar 22, 2006 at 01:25:47PM -0300, Gaston Dombiak wrote: >>> >>> Hey Norman, >>> >>> >>> >>> Wildfire implementation is based on >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-sasl-plain-08.txt. My >>> >>> understanding after reading " >>> >>> The mechanism consists of a single message, a string of [UTF-8] >>> >>> encoded [Unicode] characters, from the client to the server. The >>> >>> client presents the authorization identity (identity to act as), >>> >>> followed by a NULL (U+0000) character, followed by the >>> >>> authentication >>> >>> identity (identity whose password will be used), followed by a >>> >>> NULL >>> >>> (U+0000) character, followed by the clear-text password." >>> >>> >>> >>> is that the client MUST include the user and password in the <auth> >>> >>> PLAIN >>> >>> stanza. I don't see any option for sending an empty <auth> PLAIN >>> >>> stanza and >>> >>> expecting the server to send a challenge so that the client can send >>> >>> the >>> >>> user and password information. Have I missed something here? :) Yes, that the "single message" defined here may be either carried in the PDU the client sends to initiate the PLAIN exchange, or sent in response to initial challedge (In the case the client sends no mechanism data in its message that indicates the exchange. >> >> >> >> The point is that SASL allows for two different ways of conveying the >> >> so-called initial response (a similar thing happens with 'additional >> >> data on success'). Correct. These cases are illustrated in section 5 of the [SASL-PLAIN]. > >rfc2222bis (just approved by the IESG for publication as an RFC to > >superseded RFC 2222) states: > > > >****** > > > > Some mechanisms specify that the first data sent in the authentication > > exchange is from the client to the server. Protocols may provide an > > optional initial response field in the request message to carry this > > data. Where the mechanism specifies the first data sent in the > > exchange is from the client to the server, the protocol provides an > > optional initial response field, and the client uses this field, the > > exchange is shortened by one round-trip: > > > > C: Request authentication exchange + Initial response > > <additional challenge/response messages> > > S: Outcome of authentication exchange > > > > Where the mechanism specifies the first data sent in the exchange is > > from the client to the server and this field is unavailable or unused, > > the client request is followed by an empty challenge. > > > > C: Request authentication exchange > > S: Empty Challenge > > C: Initial Response > > <additional challenge/response messages> > > S: Outcome of authentication exchange > > > > Should a client include an initial response in its request where the > > mechanism does not allow the client to send data first, the > > authentication exchange fails. > > > >****** > > > >Now this is still not crystal clear, I think. Does "protocols may > >provide an optional initial response field" mean that "optionally, a > >protocol may require the client to send the initial response" or does it > >mean "a protocol may specify a way for the client to send the initial > >response, and sending the initial response is optional"? I read this as > >stating the former -- that a protocol may require the client to send an > >initial response. But I will seek clarification on this point with my > >SASL friends. The field, when provided, should generally be "optional" to the client. That is, if the protocol provides the field, its use is (by default*) at the client's option. This implies that servers must support exchanges regardless of whether the client makes use of the field or not. The same applies to the optional data on success field. If the protocol provides the field, it's the server's option (by default*) to use it. Hence clients have to deal with both cases. Now, nothing prevents an application protocol specification from restricting use of protocol options such as these. For instance, a protocol specification can say: clients MUST use the initial response field in applicable cases, and/or say: servers MUST use the additional data field in applicable cases. The problem with such MUSTs is 'applicable cases' and how that's communicated between independently developed portions of implementation (e.g., between the SASL library and the application-layer code). In general, I would recommend against such MUSTs (though a SHOULD would be good to encourage less roundtrips). Regards, Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml
