[31980] in Kerberos
Re: file-based credentials vs memory-based credentials
daemon@ATHENA.MIT.EDU (=?iso-8859-1?Q?Love_H=F6rnquist_=C)
Tue Jan 26 02:12:28 2010
Mime-Version: 1.0 (Apple Message framework v1134)
From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= <lha@kth.se>
In-Reply-To: <4B56F889.4090800@inria.fr>
Date: Mon, 25 Jan 2010 23:12:13 -0800
Message-Id: <B182904E-8256-4018-B56D-C3015AA616B3@kth.se>
To: Guillaume Rousse <Guillaume.Rousse@inria.fr>
Cc: "Kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Hello,
> I sometimes hears than kerberos 5 security is lowered by the use of file
> based credentials, whereas kerberos 4 was using shared memory instead,
> making much more difficult to an admin (for instance) to retrieve a
> valid user ticket.
kth-krb never had shared memory credentials, dunno about MIT Kerberos.
> I know an admin user can scan the memory for a user ticket, but a quick
> google search on the issue didn't returned any such tool ready for user.
> And unless some string pattern make easy to grep /proc/kcore for
> extracting those ticket, is this assertion reserved to admins able to
> craft a dedicated memory scanning tool ?
>
> Also, I've read than kerberos 5 specification doesn't enforce one or the
> other kind of storage, that's just MIT and heimdal implementation
> choices. Are they any way, for both of them, to use memory-based
> credential cache instead ?
Heimdal also supports kcm, which is a credential cache server. That brings credentials into memory, but that is probably not so exciting. Currently its most like a ffile like interface between libkrb5 and kcm.
Eventually it will support doing krb5_mk_req() in the process so the keys never will leave kcm.
Love
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
