[OpenAFS-devel] Re: openafs - proposed cache security improvement

[Marcus Watts]

"Sean O'Malley" <omalleys@msu.edu> writes:
> On Mon, 26 Mar 2007, Jeffrey Altman wrote:
> 
> > Do you have AFS Servers running on the portables?  In this solution it
> > is the server that is given a key, not the clients.
> 
> This is going to work backwards from most implementations?
> We create a unique key on the clients, and they use that to do a kerberos
> key style key exchange? but backwards because the client is considered
> trusted and the server isn't? Are we protecting against spoofed clients or
> spoofed servers? or just worried about eavesdropoping?

In this case, spoofed servers.  Regular kerberos works because
it's not protecting a shared resource.  In this case, there's
a shared resource involved, so there needs to be something extra.
I hope you have your kerberos servers & file servers straight
in your head.

> 
> > If the clients have a key, then they can just use Kerberos.
> 
> If you use kerberos, it still isnt going to work with a detached network
> is it? I thought the hostkey was still verified by the kerberos server
> even though it is "trusted".

You must be thinking of "krb5_verify_init_creds".  In this case, the
kerberos server does not "verify" the host key.  The kerberos server
returns a service ticket for the "host key".  The local client machine
verifies that it is not talking to a spoofed kdc by determining that the
service ticket returned can be decrypted by the local key.  This is
different than what I'm proposing, because I'm not talking about
initial authentication at all.  You are right, it would be difficult to
use kerberos to supply a host key for your laptop.  That's why I didn't
propose using kerberos for this, but talked about public keys instead.

> 
> And the users passwords still had to be trusted by the authentication
> server. How is this going to work on a client machine detached from the
> network?

It won't.  If you're detached from the network then you can't use
kerberos or any service tickets.  You also can't talk to any file
servers, so you don't have any worries.

> 
> > If you are using Windows, you can encrypt your cache today.  Just mark
> > the page file directory as encrypted.  The SYSTEM account key will be
> > used to encrypt the file.
> 
> Im not really worried about an encrypted filesystem persay that has been
> done for years and years with hundred of different algorithms.
> 
> I am concerned about multi-user machines, and stolen laptops with
> sensitive data. You want users being able to use it detached from the
> network but yet securely acrossed all platforms.
> 
> I don't know how to get around this one to be honest at some point the
> security model breaks without 2nd party (at least) verification. Even a
> key stored somewhere could be hacked by an admin user. I don't know maybe
> my ideal of secure, is too secure to be implemented... I was just trying
> to find a better way.. (and yes i do realize even security model breaks
> down at some point.)

I'm assuming the multi-user machine is run in a heavily fortified
server room with round the clock armed guards, gas pressurized network
feeds, and the only who have root first spend a year being trained in a
tiger penetration team before being given 3 months off for good
behavior.  Ie, I'm assuming the machine itself is secure.  I'm also
assuming the file server & kerberos servers are run similarly, but --
key assumption here, I'm assuming all those fancy high-security network
feeds go into a small wooden shack on a remote deserted island with a
flimsy wooden door which isn't kept locked.  Ie, the network can't be
trusted.  I'm also assuming some of your fellow users on that
multi-user machine are unsavory types with larcenous tendencies and
connections to nocturnal low-draft duty-free shipping concerns.  Ie,
people you don't trust.  There's more than two parties wandering around,
in fact, I think I see a conga line forming on the suspicious fishing
vessel out near the deserted island.

Your laptop is a different kettle of fish.  You actually still
want my security improvements, but you would probably rather I were
not using a kerberos host key here.  What you would get here are
secure anonymous connections -- in some ways comparable to
using "https", but for afs access and hopefully more efficient.
It might actually give you some privacy against eavesdroppers for
those times when you haven't yet authenticated yourself via kerberos.
What I'm proposing won't help with thugs who steal your laptop,
nor will it help any if you don't trust the people who administer
the software on your laptop.

...

			-Marcus Watts