Kerberos vs. LDAP for authentication -- any opinions?
cybe...@yahoo.com
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: cybe...@yahoo.com
Jeffrey Altman
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.
Harry Le
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
________________________________________________
Kerberos mailing list Kerb...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
________________________________________________
Kerberos mailing list Kerb...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
wang, ye
login admin user will be able to do it. Actually, LDAP server is an
authentication service provider.
Jeffrey I. Schiller
General rule: Your password should only be accessible to a trusted computer.
There are three computers in a potential transaction.
1. The Client Computer -- Trusted
2. The KDC/LDAP Server -- Trusted
3. The Server -- UNTRUSTED
When using Kerberos you enter your password into your (trusted)
client. It performs a transaction with the server which permits the
server to authenticate you. However the server never gets your
password, so it doesn't have to be trusted to not abuse it.
With LDAP you authenticate to the server by sending the server your
username and password (hopefully over a secure or encrypted path). The
Server then supplies your username and password to the LDAP server
(again, hopefully over a secure or encrypted path). The LDAP server
then returns to the server whether or not the username/password pair
were valid. In this scenario the SERVER has access to the unencrypted
user password. If it is not trusted, then it might steal it. This is
why LDAP isn't a good solution for authentication.
In many cases client computers are necessarily trusted (like my
laptop, which I own and control). One must necessarily trust the
authentication server, whether it is a Kerberos KDC or an LDAP
server. However it is often the case that you don't want to have to
trust the server. Here Kerberos wins and LDAP loses.
-Jeff
Tim Alsop
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.
Not entirely true.
Joseph
Kevin Coffman
which then uses SASL/GSSAPI to verify the password? Isn't that how this
works, or am I missing something?
K.C.
-----Original Message-----
From: kerberos...@mit.edu [mailto:kerberos...@mit.edu] On Behalf
Of Harry Le
Sent: Wednesday, January 28, 2004 2:30 PM
To: kerb...@mit.edu
Jeffrey Altman
LDAP is being used for authorization. This is not the same
as using LDAP for authentication.
Jeffrey Altman
Andreas
> But it does require you to send your password (over SSL) to the LDAP server
> which then uses SASL/GSSAPI to verify the password? Isn't that how this
> works, or am I missing something?
No, you are talking about using something like {SASL}stuff in the userPassword
attribute, which is still a simple bind from the client's point of view.
> -----Original Message-----
> From: kerberos...@mit.edu [mailto:kerberos...@mit.edu] On Behalf
> Of Harry Le
> Sent: Wednesday, January 28, 2004 2:30 PM
> To: kerb...@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
Russ Allbery
> 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.
LDAP "authentication" is actually nothing more or less than using your
LDAP directory servers as a giant distributed /etc/shadow file. You can
put the password checking in various places, but in the end you're
basically taking a step backwards towards something more like the
historical Unix authentication mechanism.
This means you lose all of the benefits of Kerberos (reusable credentials,
passwords never crossing the network encrypted or not, ticket forwarding,
etc.) in favor of something that's basically secure NIS. If secure NIS is
something you're happy with, hey, great, but to me it feels like 1980s
security technology, long-since obsolete.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Frank Cusack
> Anyone have any pointers to information about the relative merits
> of using Kerberos or LDAP for authentication in a large heterogeneous
> environment?
I think other responses are missing the bigger picture.
You are almost certainly (I'd bet on it) not using Kerberos
authentication as $DEITY intended, ie obtaining a TGT on your local
(trusted) host then using that to get service tickets for
applications.
If you were, replacing it with LDAP would be out of the question, as
you'd lose SSO.
If that's the case, you're better off using LDAP. You need LDAP
anyway, you said you have an established LDAP infrastructure, and it's
harder to do krb5 authentication correctly than LDAP. Of course,
there's work involved in setting up LDAP well, but if you are using
LDAP at all, you have to do that anyway. Better to only maintain less
infrastructure.
Ideally, you'd use real Kerberos authentication for your applications
and just use LDAP for authorization. That's a far superior method;
see the Kerberos FAQ.
And SASL/GSSAPI has no bearing; if you're using GSSAPI you're using krb5
(for authentication).
/fc
Douglas E. Engert
cybe...@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.
What is the real situation.
Are these people application developers who find it easier to just
ask for a user and password then call LDAP?
Are they looking at the lack of Kerberos in the browser, and so
find the easiest way is to just prompt for a user and password?
Are they application developers who want additional authorization data
which is store in LDAP which Kerberos can not provide?
Many of the Browser issues can be addressed by Kx509 from the
Univrsity of Michigan. It can obtain a short term X509 certificate
using Kerberos for authenticaiton. The certificate and key are then
stored so the browser can use it with SSL to any web server. It works
with IE and Netscape on Windows. It runs on UNIX and Mac as well.
http://www.citi.umich.edu/projects/kerb_pki/
Once authenticated, LDAP can still be used for authorization data.
>
> 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: cybe...@yahoo.com
> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
--
Douglas E. Engert <DEEn...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Peter Gietz
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:
--
_______________________________________________________________________
Peter Gietz (CEO)
DAASI International GmbH phone: +49 7071 2970336
Wilhelmstr. 106 Fax: +49 7071 295114
D-72074 Tübingen email: peter...@daasi.de
Germany Web: www.daasi.de
Directory Applications for Advanced Security and Information Management
_______________________________________________________________________
Tim Alsop
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.
Peter Gietz
> 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
David Magda
[...]
> usernames and passwords across the network to a potentially
> compromised machine in order for them to be validated against the
> copies stored in LDAP.
[...]
And what prevents a Kerberos server from being compromised? Any
system can have a root-kit installed on it.
--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
Garrett Wollman
David Magda <dmagda+tr...@ee.ryerson.ca> wrote:
>And what prevents a Kerberos server from being compromised? Any
>system can have a root-kit installed on it.
The fact that nobody has access to it (assuming it was competently
installed).
-GAWollman
--
Garrett A. Wollman | As the Constitution endures, persons in every
wol...@lcs.mit.edu | generation can invoke its principles in their own
Opinions not those of| search for greater freedom.
MIT, LCS, CRS, or NSA| - A. Kennedy, Lawrence v. Texas, 539 U.S. ___ (2003)
Jeffrey Altman
>
> And what prevents a Kerberos server from being compromised? Any
> system can have a root-kit installed on it.
Simple. You don't run any other services on your KDC.
All access is via physical connections. Small network footprint
results in extremely low chance of hacking.
Dr. Greg Wettstein
} Subject: Re: Kerberos vs. LDAP for authentication -- any opinions?
> Many of the Browser issues can be addressed by Kx509 from the
> Univrsity of Michigan. It can obtain a short term X509 certificate
> using Kerberos for authenticaiton. The certificate and key are then
> stored so the browser can use it with SSL to any web server. It works
> with IE and Netscape on Windows. It runs on UNIX and Mac as well.
> http://www.citi.umich.edu/projects/kerb_pki/
Didn't Whit Diffey file a patent which covered the concept of using
short-term certificates as authentication brokers?
If so does the Kx509 stuff have some sort of divine absolution with
respect to it?
}-- End of excerpt from "Douglas E. Engert"
As always,
Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC.
4206 N. 19th Ave. Specializing in information infra-structure
Fargo, ND 58102 development.
PH: 701-281-1686
FAX: 701-281-3949 EMAIL: gr...@enjellic.com
------------------------------------------------------------------------------
"Don't worry about people stealing your ideas. If your ideas are any
good, you'll have to ram them down people's throats."
-- Howard Aiken
Sam Hartman
David> And what prevents a Kerberos server from being compromised?
David> Any system can have a root-kit installed on it.
The issue is that in the Kerberos model, compromising a mail server or
web server etc doesn't get you much, but in the LDAP model it gets you
passwords. The Kerberos server itself is still an interesting target
in many Kerberos deployments.
Jeffrey I. Schiller
to protect all servers.
In our situation we have security people running the Kerberos server
and we are paranoid about how it is maintained. Generic servers on the
otherhand can be (and are) run by all sorts of people, many who have
little security clue.
-Jeff
Dan Geer
> And what prevents a Kerberos server from being compromised? Any
> system can have a root-kit installed on it.
I am hoping that this is not flame bait...
Clearly, unless you want to reinvent the classic idea
of provably correct systems, you will/must make some
tradeoffs in the real world because provable security
is never affordable just as affordable security is
never provable.
As such, single purpose machines running open-source
security code on stripped platforms, watched like a
hawk by competent paranoids, and speaking only well
beaten crypto over well beaten protocols will win.
Kerberos fits that bill to a Tee; you can bust into
the inner sanctum, grab the KDC, and dive out the
window into your waiting getaway vehicle only to
discover that what you have is a brick. You can try to
remotely attack it and install whatever you want, but
there is very little attack surface plus you'll have to
be smarter/luckier than the several hundred genuine
worthies who've already come up dry. If you want to
find something to fear in a large scale Kerberos plant,
fear keystroke capture on serially reusable client
machines or the ever-available "key purchase" attack.
--dan
paul kölle
> 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.
>
sorry, but where is the point? If you use SASL/GSSAPI, you have to
deploy kerberos right? Then the "vs." is gone and the directory is just
another kerberized recource of information. Using the abovementioned
{SASL}<cleartextpw> hack, to access kerberos passwords thru simple binds
is (like pam_krb5) a bad choice (and disabled in newer OpenLDAP
releases) since it opens your kerberos database to non-kerberized
services which send (possibly) passwords thru the net in the clear.
greetings
Paul
Christian Nordmann
> Ideally, you'd use real Kerberos authentication for your applications
> and just use LDAP for authorization. That's a far superior method;
> see the Kerberos FAQ.
That's what i ended up with! I'm currently implementing that at work.
Authentication via Kerberkos and authorization via LDAP. Glued together
with a half done PAM-Module (still in development and heavily depending
on heimdal utilities reverse engineering).