[jdev] Re: tls + plain sasl not working

[Ralph Meijer]

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? :)

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').

1. The SASL profile defines a way to send along the initial response
with the start of the authentication exchange in one message. The XMPP
SASL profile allows for this in by putting this data in the <auth/>
element as CDATA.

2. The protocol using SASL doesn't provide that ability. This is solved
by having the server send an empty challenge, to which the client
responds with the initial response. An example of this is the IMAP SASL
profile.

(Very) unfortunately, the MD5-DIGEST examples in RFC 3920 (XMPP Core)
use method #2, basically because the most prominent use of SASL is in
IMAP. This will be rectified in RFC 3920bis

Now, the question really is: if you (as a SASL profile) support method
#1, do you also have to support #2? 

-- 
Groetjes,

ralphm