Kerberos vs. LDAP for authentication -- any opinions?
Peter Gietz
peter.gietz at daasi.de
Thu Jan 29 12:14:04 EST 2004
Tim Alsop wrote:
> Peter,
>
> Thankyou for the explanation. I was trying to keep my answer
> relatively simple to avoid any unnecessary technical detail and hence
> over complicate the answer to the original question asked.
>
> Anyway, Kerberos is useful for more than just SSO (or SSSO) when
> comparing with LDAP, this is why I provided a long list of differences
> in my email. In fact LDAP and Kerberos are complimentary and not
> competitive technologies.
>
Exactly.
There are more than one way to combine the two technologies. Heimdal can
for example have LDAP as database backend for Kerberos data.
Cheers,
Peter
> Thanks, Tim.
>
> -----Original Message-----
> From: Peter Gietz [mailto:peter.gietz at daasi.de]
> Sent: 29 January 2004 16:58
> To: Tim Alsop
> Cc: Harry Le; kerberos at mit.edu
> Subject: Re: Kerberos vs. LDAP for authentication -- any opinions?
>
> Tim,
>
> Your view on LDAP may be a little too simplified.
>
> There is a whole variety of authentication mechanisms that you can use
> within LDAP, userdn/cleartext password (=simple bind) being only the
> most useless and unrecommended by the standards.
>
> The minimal recomendation is to use that simple bind within a TLS
> encrypted session, but there are other mechanisms in LDAP
> implementations which all use the SASL framewrk. The IMHO most
> important SASL mechanism are:
>
> - DIGEST MD5 a challenge response mechanism, where the actual password
> will not be sent through the net. This is also mandatory to implement
> in standard conforming LDAP
>
> - GSSAPI using the Kerberos 5 mechanism, which was allready mentioned
> in this thread, and is implemented in at least some LDAP
> implementations, like OpenLDAP.
>
> Any other SASL mechanisms could also be used, e.g. SASL EXTERNAL,
> which can use client certificate based strong authentication, allready
> established in lower layers, like TLS
>
> What I want to say is that LDAP can well be and is being used as
> authentication infrastructure. The main advantage of Kerberos is its
> SSO functionality. But again with GSSAPI/KRB5 you can integrate that
> in an LDAP authentication infrastructure as well. The advantage of
> LDAP is IMO that it can be used for more than authentication, e.g.
>
> authorization, contact data information system, certificate server, etc.
> etc.
>
> Cheers,
>
> Peter
>
>
> Tim Alsop wrote:
>
> >Harry, others,
> >
> >The SASL/GSS mechanism supported by the LDAP server is used to
> securely access the directory. Using SASL/GSS and LDAP does not help
> authenticate a user so he/she can use an application which then
> presents the users identity to another application components in a
> secure manner - this is one of the many requirements for application
> security which Kerberos is idealy suited.
>
> >
> >I think we need to compare the LDAP directory and Kerberos protocol
> in order to answer the original question asked. Admitedly, if SASL/GSS
> is used to securely access a directory so that a password can be read
> and compared, then LDAP can be used to authenticate a user.
>
> >
> >I have provided a short list of some differences, not necessarily a
> complete list so maybe others on this email discussion can add
> comments and think of other important differences ?
>
> >
> >LDAP server for user authentication
> >- can be used to store password + other information about users.
> >- useful for simple user authentication requirements where checking
> of password is all that is required.
> >
> >Kerberos for user authentication
> >- uses security credentials which have a lifetime - LDAP does not have
> >this capability
> >- built in prevention from network replay attacks and protect against
> >other network security concerns - LDAP does not protect against these
> >issues
> >- removes the need to pass any form of password across a network - LDAP
> >requires password transmission
> >- A protocol that alows support for userid/password, token card, smart
> >card authentication and other forms of user authentication - LDAP is
> >only suited to userid/password
> >- works well in a client/server and multi-tier environment especially
> >when using credential delegation or impersonation
> >- can be used to setup a security context between application
> components on the network - LDAP cannot be used for this.
>
> >- provide mutual authentication, integrity, confidentiality services -
> >LDAP does not do any of these
> >- makes single signon easy, especially since Microsoft Active Directory
> >does the Kerberos authentication when a user logs onto a MS network
> >- works well in a heterogeneous environment
> >- supported and utilised by a growing number of application vendors and
> >standards
> >- a strategic protocol in many ways because of having many uses - it
> can even be used very effectively to allow an unattended application
> to authenticate itself to another application (e.g. ftp -> ftpd).
>
> >
> >Thanks, Tim.
> >
> >-----Original Message-----
> >From: Harry Le [mailto:sahung at rogers.com]
> >Sent: 28 January 2004 19:30
> >To: kerberos at mit.edu
> >Subject: RE: Kerberos vs. LDAP for authentication -- any opinions?
> >
> >
> >Not entirely true.
> >
> >Most LDAP servers now support the SASL/GSSAPI mechanism. It uses
> Kerberos
> >V5 credentials to authenticate users against LDAP directories. This
> will not require users to change passwords. For data privacy, use SSL.
>
> >
> >Joseph
> >
> >-----Original Message-----
> >From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On
> >Behalf Of Jeffrey Altman
> >Sent: Wednesday, January 28, 2004 11:19 AM
> >To: kerberos at mit.edu
> >Subject: Re: Kerberos vs. LDAP for authentication -- any opinions?
> >
> >LDAP is not an authentication infrastructure.
> >All you are doing with LDAP is providing a database of usernames and
> passwords which is accessible over the network. Your users must then
> transmit said usernames and passwords across the network to a
> potentially compromised machine in order for them to be validated
> against the copies stored in LDAP.
>
> >
> >To me this approach is unacceptable.
> >
> >
> >cyberp70 at yahoo.com wrote:
> >
> >
> >>At the risk of starting a religious war....
> >>
> >>We currently use Kerberos for authentication for almost everything on
> >>our network. Some people here are advocating switching to using LDAP
> >>for authentication (we already have a pretty well developed LDAP
> >>infrastructure). This would of course require everyone to change
> >>their password as well the trauma of recoding applications that
> >>currently use Kerberos and haven't been converted to using PAM.
> >>
> >>Anyone have any pointers to information about the relative merits of
> >>using Kerberos or LDAP for authentication in a large heterogeneous
> >>environment?
> >>
> >>Any info is, of course, greatly appreciated.
> >>
> >>- C
> >>
> >>--
> >>Email: cyberp70 at yahoo.com
> >>
> >>
> >________________________________________________
> >Kerberos mailing list Kerberos at mit.edu
> >https://mailman.mit.edu/mailman/listinfo/kerberos
> >
> >________________________________________________
> >Kerberos mailing list Kerberos at mit.edu
> >https://mailman.mit.edu/mailman/listinfo/kerberos
> >________________________________________________
> >Kerberos mailing list Kerberos at mit.edu
> >https://mailman.mit.edu/mailman/listinfo/kerberos
> >
> >
>
>
> --
> _______________________________________________________________________
>
> Peter Gietz (CEO)
> DAASI International GmbH phone: +49 7071 2970336
> Wilhelmstr. 106 Fax: +49 7071 295114
> D-72074 Tübingen email: peter.gietz at daasi.de
> Germany Web: www.daasi.de
>
> Directory Applications for Advanced Security and Information
> Management
> _______________________________________________________________________
>
--
_______________________________________________________________________
Peter Gietz (CEO)
DAASI International GmbH phone: +49 7071 2970336
Wilhelmstr. 106 Fax: +49 7071 295114
D-72074 Tübingen email: peter.gietz at daasi.de
Germany Web: www.daasi.de
Directory Applications for Advanced Security and Information Management
_______________________________________________________________________
More information about the Kerberos
mailing list