Re: Wishlist: credential file update/access collision avoidance?

"Roland C. Dowdeswell" <[email protected]>
Newsgroups gmane.comp.encryption.kerberos.heimdal.general
Message-ID <[email protected]>
On Mon, Oct 03, 2011 at 10:19:53AM +0200, [email protected] wrote:
>

> Depending on what is considered to be a "correct operation" it
> may be true or not. For my purposes it would work very well to share
> credentials between my processes on several computers of the same security
> domain. A protected shared file system would be ok (why not?), even a
> distributed one - if it provides strong authentication, authorization and
> confidentiality which e.g. Coda does.
> 
> In general, ccaches are not "local credentials", their contents is to be
> used in a distributed context. The local credential of a process in Unix
> is its uid (and gid and possibly some more things but you get the idea).
> 
> So I can not agree with your statement.

Well, given that the historical best practices for Kerberos tickets
was to put addresses in them, I think that we can see that they
were not meant to be shared between computers without actually
being explicitly forwarded from one computer to the other.

I think that this is still widely held as best practice.  IIRC,
addressless tickets were defined as the norm, not so that you could
put your ccaches on distributed file systems but rather because
addresses cause many issues with NAT and multi-homed host but do
not provide a terribly strong additional security component.

> So I do not suggest putting ccaches on distributed file systems as a
> default, this should be done with great care, but nothing says
> that it is impossible, never useful or inherently insecure.

This likely means that the documentation should be updated.

> On the other side I an unhappy with the state of specification and
> documentation around ccaches. Different people apparently have different
> views on the semantics and there is hardly a certainty about what a
> developer thinks when (s)he writes Kerberos-related code. Not good for
> security in the code, nor for secure practices at deployment.

Agreed.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.