Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (hermes.apache.org: domain of vinod.p@gmail.com designates
 64.233.184.193 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=HBS/5SUG52+9QXNk510l345LG39YnKggP5Zu7QDICRzJs0YB6nrfNk31t1CnkI+koZNtotPkQ8VBX5F0RtkSbfo7hMxjT+qeaKywSlafpqmcOgr71nmgmpkvajlCgjuMjaJv0KI9xgPEGOitjsmHIoc3e4k2DFVBaniKetqhWaY=
Message-ID: <a8f18ca30505060601254be1e0@mail.gmail.com>
Date: Fri, 6 May 2005 18:31:13 +0530
From: Vinod Panicker <vinod.p@gmail.com>
Reply-To: Vinod Panicker <vinod.p@gmail.com>
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [mina] SASL support
In-Reply-To: <427A1495.7040205@bozemanpass.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <a8f18ca305050505306f9f9410@mail.gmail.com>
	 <427A1495.7040205@bozemanpass.com>

OK, here's the explanation that I promised.

On 5/5/05, David Boreham <david@bozemanpass.com> wrote:
> Vinod Panicker wrote:
>=20
--snip

> Actually I don't think so. There are two aspects to SASL:
> authentication and 'encryption'. What you are saying is correct
> for the authentication part : for example in the case of LDAP
> the SASL payload is sent inside the regular BIND request PDU.

There is no "encryption" aspect to SASL.  SASL simply acts as a
container or as a definition of a challenge-response technique for
authentication.  The actual authentication is implemented by
mechanisms.  SASL was designed to be extensible - that is why there
are many different mechanisms that are available today.  Encryption as
a function would be specific to a mechanism.  Even I can define a new
mechanism tomorrow and have the data being transmitted over the wire
encrypted.  IMHO, the implementation of encryption/any other
functionality should be done within a mechanism.  It would be wrong to
state that this functionality is part of "SASL" - its part of a
"Mechanism".  Refer to http://www.iana.org/assignments/sasl-mechanisms
for a list of all registered SASL mechanisms.

>=20
> However, for 'sasl encryption' the actual packets sent on the wire
> are wrapped by an encryption layer in much the same way as
> SSL. In implementing this it is necessary to get at the raw byte
> stream from the socket. To me this looks exactly like task for a mina
> filter.

Disagree.  The SASL payload is supposed to be carried by the host
protocol, which can have its own way of defining how it will carry the
SASL payload.  It basically has to provide a conduit for the SASL
challenges/responses.  SSL is different in the sense that its at the
Transport layer.  The SASL payload is carried by an Application layer
protocol.  Its not necessary to get the raw byte stream since the
carrier protocol might state that the SASL payload has to be encoded
in a certain format - eg base64.  Here, the SASL data would be sent as
ASCII text.

>=20
> Now, it turns out that not many deployed apps actually use
> sasl encryption. The one I'm most familiar with is Kerberos.
> i.e. if you initiate an LDAP session with SASL and the Kerberos
> mechansim, you can negotiate encryption using SASL, which
> actually ends up being done by Kerberos. Same goes I believe
> for at least one of the MD5-based mechanisms.
>=20
> Quite a few existing LDAP servers support SASL encryption, FWIW.
>=20
> See the Cyrus SASL kerberos plugin source code for more
> details on this.
>=20

TLS is the perfect candidate for a MINA filter since it will
manipulate *all* data being sent over the wire.  An SASL mechanism
requiring encryption isnt coz the carrier protocol might define a
specific method of wrapping it.  MINA has to be protocol agnostic.=20
Also, the SASL sequence comes into play usually only once for a user
session, whereas a filter is designed to be for a longer period -
mostly for the entire session.

Hope this makes it clear as to why having an SASL filter in MINA would
be a bad design decision.

Regards,
Vinod.