[jdev] Re: tls + plain sasl not working

[Peter Saint-Andre]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

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.

Peter

- --
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEIYPwNF1RSzyt3NURAvXMAJ0UjtBCqtUDTsyibO3PksT3yFhG+QCgp82e
DStE3FBP1eymjLCP3PhLOmg=
=G8CG
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://www.jabber.org/jdev/attachments/20060322/b714edd1/attachment-0002.bin>