[OpenAFS-devel] RT, Gerrit, Release Management changes

[Troy Benjegerdes]

On Sun, Oct 07, 2012 at 08:53:48AM -0700, Booker Bense wrote:
> On Fri, Oct 5, 2012 at 9:02 PM, Ken Hornstein <kenh@cmf.nrl.navy.mil> wrote:
> >>> Would it be feasible for us to 'eat our own dogfood', so to speak, and
> >>> use SPNEGO and cross-realm Kerberos to log into RT? (If this is already
> >>> implemented, and I haven't noticed, then I will volunteer myself to go
> >>> document it better)
> >>
> >>Cross-realm isn't really a workable solution unless you have tight coordination
> >>between realms and general agreement about security policies.
> >
> > That has NOT been my experience, and we use cross-realm a lot (probably
> > more than most sites).  I think there's no reason why we couldn't do
> > what Troy is suggesting (other than the kinda pain-in-the-ass part of
> > actually setting up cross-realm).
> 
> 
> The technical part of cross-realm works just fine, it's the political
> part that becomes difficult.
> If for instance, the people that give you money want to implement a
> policy in which all keys
> in the KDC are updated every six months, then you have to do the PITA
> part with all
> the other realms every six months. And how do you justify to auditors
> that the people you're
> letting in from the remote realm follow your policies for account verification?

Depending on people who insist on rolling all keys every 6 months *and*
continue to ignore DES-key brute force potential to continue to give you 
money is not a position I would want to be in. 

My take on the political layer obstacles to cross-realm is to figure out
a way to leverage DNSSEC in some way to facilitate no-administrator
intervention cross realm key exchange.

Administrators (should be) used to automatically rolling out DNSSEC keys,
and there ought to be some reasonable way to generate a (temporary) shared
secret using DNSSEC as a basis to trust other realms.

I would make the political layer argument that utilizing outside services
is a business requirement, and the policies and audits need to reflect this.
DNSSEC provides an easy 'everyone else is doing it' solution, even if it has
security problems, as the alternative is your users uploading sensitive data
to Dropbox, iCloud, Google drive, etc.

What you could do with DNSSEC+Kerberos+AFS as a functional alternative is 
monitor which outside realms your users *actually* share data with, and then
start negotiating with the auditors and administrators of the top 3 other
realms to implement direct secure cross realm trust, along with sharing of
logfiles and threat monitoring.

Even with the AFS DES problem, 56 bit Keyfile(s) and cross realm trust 
is still better than a cloud service with an average user password of
between 27 and 45 bits (if I'm reading the paper at 
cups.cs.cmu.edu/rshay/pubs/passwords_and_people2011.pdf correctly)

As far as I know, AFS+Kerberos is the only solution capable of offering
something like this, and presenting administrators and security folks some
ability to know where the keys to their sensitive data are. If someone 
uploads a document to a cloud service, you have no idea if someone at a
provider's foreign office has made off with the entire password database
and is running an offline cracker on it. I haven't seen Google, Dropbox,
Apple, Microsoft, Amazon, or any other .com detail how they secure their
password databases from insider threats. I have seen discussions from .edu
and .gov sites that at least talk about it, and it still seems to me that
a hardened unix MIT or Heimdal Kerberos server, with some good security 
guys with good logfile analytics is about as good as it gets.