Re: Kerberos/LDAP/SASL central authentication server howto

[Markus Moeller <huaraz@moeller.plus.com>]

Nikola,  
  
If you look athe the slapd.conf help you find:  
 
sasl-secprops <properties> 
              Used to specify  Cyrus  SASL  security  properties.  
              The  none  flag  (without  any  other  properities)  
              causes     the     flag     properites     default,  
              "noanonymous,noplain",  to be cleared.  The noplain  
              flag  disables  mechanisms  susceptible  to  simple  
              passive   attacks.    The  noactive  flag  disables  
              mechanisms  susceptible  to  active  attacks.   The  
              nodict  flag  disables  mechanisms  susceptible  to  
              passive dictionary attacks.   The  noanonyous  flag  
              disables  mechanisms which support anonymous login.  
              The forwardsec flag require forward secrecy between  
              sessions.   The  passcred  require mechanisms which  
              pass client credentials (and allow mechanisms which  
              acceptable  security  strength factor as an integer  
              approximate  to  effective  key  length  used   for  
              encryption.   0  (zero)  implies  no  protection, 1  
              implies integrity protection only, 56 allows DES or  
              other weak ciphers, 112 allows triple DES and other  
              strong ciphers, 128 allows RC4, Blowfish and  other  
              modern  strong  ciphers.   The  default  is 0.  The  
              maxssf=<factor>  property  specifies  the   maximum  
              acceptable  security  strength factor as an integer  
              (see minssf description).  The default is  INT_MAX.  
              The   maxbufsize=<size>   property   specifies  the  
              maximum security layer receive buffer size allowed.  
              0  disables security layers.  The default is 65536.  
  
I tried to use the -O minssf=128 with ldapsearch against AD, but get a failure although I use the latest heimdal library which supports 
rc4-hmac. I can see that I have an arcfour-hmac-md5 ticket for the ldap/server principal and would assume that rc4-hmace allows the 
higher encryption. 
 
Any ideas why not ? 
 
Thanks 
Markus 
 
  
  
  
On Tue, 10 Aug 2004 10:54 , Nikola Milutinovic <Nikola.Milutinovic@ev.co.yu> sent:  
  
>This is a cross-post to Cyrus INFO list. The question raised here is   
>whether GSS-API and *-MD5 SASL mechanisms secure the entire   
>communication, not just the authentication phase, thus making SSL/TLS   
>unnecessary.  
>  
>Tarjei Huse wrote:  
>  
>>>>?? I didn't know , sorry. Please tell me more on how I can use GSSAPI instead of  
>>>>tls to secure not only authentication but everything that happens over the  
>>>>wire.  
>>>  
>>>It really depends on the client tool. Not only does GSSAPI provide this, DIGEST-MD5  
>>>also.  
>  
>Never heard of this. I was always under the impression that both GSS-API   
>and *-MD5 methods secured only the authentication, not the entire   
>channel data transfer.  
>  
>>>Examples of such tools that I'm 100% aware of are ldapsearch and mutt when doing SASL  
>>>authentication.  
>>>  
>>>With ldapsearch, for example:  
>>>$ ldapsearch -h ldap.server | head -5  
>>>SASL/GSSAPI authentication started  
>>>SASL username: andreas@DISTRO.CONECTIVA  
>>>SASL SSF: 56    
>  
>No. It simply means that authentication type is of SSF (Security   
>Strength Factor) 56. I'm not sure if the SSF has anything to do with   
>number of bits used as (some) private key length. Anyway, this is saying   
>nothing about the rest of the communication, just the authentication part.  
>  
>>>SASL installing layers  
>>>(...)  
>>>  
>>>With digest-md5:  
>>>$ ldapsearch -h ldap.server -Y digest-md5 | head -5  
>>>SASL/DIGEST-MD5 authentication started  
>>>Please enter your password:  
>>>SASL username: andreas  
>>>SASL SSF: 128    
>  
>Again, just the auth phase is covered here.  
>  
>I'm crossposting to the SASL mailing list in hopes someone can shed some   
>light on the matter.  
>  
>Nix.  
--   
Markus Moeller <huaraz@moeller.plus.com>