directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinod Panicker <>
Subject Re: [mina] SASL support
Date Sun, 08 May 2005 07:48:50 GMT
On 5/7/05, David Boreham <> wrote:
> >>
> >> 4 - parse the application protocol so it can get the SASL payload
> >
> It occurred to me that this might be why you're confused about this.
> In the case of LDAP, your statment above is incorrect (I don't know
> anything about SASL with other protocols, so you may well be correct in non-LDAP cases).
> With LDAP, SASL encryption is layered _below_ the application procotol.
> That is, the encryption is done on the LDAP PDU byte stream,
> potentially with framing that is not aligned with the LDAP PDUs.
> It's essentially identically the same layering scenario as SSL/TLS.
> And this is why I will not be eating my keyboard regardless of how tasty
> it might be.
> (The SASL _authentication_ payload is carried in the LDAP protocol,
> within the BIND requests and responses, but _encryption_ is done below
> the LDAP protocol).

I guess we've been talking abt different things all this while. 
You've been talking abt the optionally negotiated security layer and
i've been talking abt the actual sasl payload (challenges/responses).

I'd be doing an SASL impl with DIGEST-MD5 and EXTERNAL mechanisms in
this week for XMPP.  These mechanisms do not have an optional security
layer as the GSSAPI and Kerberos mechanisms do.  I've already done an
SASL poc using jdk 1.5 and the DIGEST-MD5 mechanism.

If the encryption is at a transport level, such as is with TLS/SSL, it
would make great sense to implement a mina filter.  But the question
since the beginning has been -

Where would you handle the SASL challenge/responses?


View raw message