[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: SASL/EXTERNAL (TLS)



At 02:14 PM 8/16/00 -0700, Howard Chu wrote:


>> -----Original Message-----
>> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
>> The authentication identity can be in any form.  I rather the
>> form be as "natural" as possible.  That is, if the authentication
>> identity is derived from an X.509 certificate, the identity
>> should be "natural" (e.g. X.500) form.
>> 
>> Once you have identity and associate session security
>> factor, you just need to let SASL know about it.  The
>> code is already prepped for the call:
>> #if 0       
>>             /* we need to let SASL know */
>>             slap_sasl_external( c, ssf, authid );
>> #endif  
>> 
>> ssf should be specified as well:
>> /* security layer strength factor -- an unsigned integer usable 
>> by the caller
>>  *  to specify approximate security layer strength desired.  Roughly
>>  *  correlated to effective key length for encryption.
>>  * 0   = no protection
>>  * 1   = integrity protection only
>>  * 40  = 40-bit DES or 40-bit RC2/RC4 
>>  * 56  = DES
>>  * 112 = triple-DES
>>  * 128 = 128-bit RC2/RC4/BLOWFISH
>>  */
>> 
>I have extracted the current encryption key length from the SSL session
>for this purpose. But is this redundant? Does specifying this ssf tell
>the SASL library to perform this level of encryption? If so, then the SASL
>encryption is being performed on top of the TLS layer's encryption. This
>would mean that we should just pass "0" when TLS is present.  

No, the SSF in this context is being provided to the Cyrus such
that it can determine whether or not to enable additional SASL
mechanisms (e.g. PLAIN).  0 would indicate a no encryption was
being provided by the lower layer (TLS), hence PLAIN would still be
restricted.