directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Boreham <>
Subject Re: [mina] SASL support
Date Fri, 06 May 2005 13:23:06 GMT
Vinod Panicker wrote:

>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
>for a list of all registered SASL mechanisms.
Unfortunately 'sasl' means many things.
However, there certainly is encryption defined in RFC2222 for the GSSAPI 
and it's in common use in the wild (RFC2222 calls it the 'security layer').
If you ever come to implement it for LDAP in Apache DS, I will eat my 
keyboard if you
do not end up writing a mina filter. You are correct that the specific 
relationship between
the security layer PDUs and the transport do depend on the application 
protocol in use.
My comments in this thread have been in the context of LDAP as the 
application protocol.

There is also encryption defined in RFC 2831 for the digest mechanism.

See the functions sasl_encode() and sasl_decode() (notice not 
in Cyrus-SASL, and the file sasl_layer.c in OpenLDAP for more inspiration.

View raw message