[Fwd: Re: [Fwd: Re: [jdev] Re: tls + plain sasl not working]]

Tue Mar 28 07:41:39 CST 2006

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 <Kurt at OpenLDAP.org>
To: Peter Saint-Andre <stpeter at jabber.org>
CC: Alexey.Melnikov at isode.com
References: <442184D5.7090401 at jabber.org>

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 <stpeter at jabber.org>
> >Reply-To: Jabber software development list <jdev at jabber.org>
> >To: Jabber software development list <jdev at jabber.org>
> >References:
> ><5b698f5a0603220643y289a45deh1f5afdce5d85383e at mail.gmail.com>
> ><dvrtqg$qk9$1 at sea.gmane.org>    <20060322164815.GA33696 at ik.nu>
> >
> >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