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

[Marcus Watts]

Rees writes:
rees> 1. Client must have a secure connection to the server even for what are now
rees> unathenticated connections
yes.
rees> 
rees> 2. Client must be able to authenticate the server
yes.
rees> 
rees> 3. It would be nice if this could be done with Kerberos rather than making
rees> afs depend on something else, like openssl and a public key infrastructure

no.  yes.

I see openssl as a useful toolkit here, especially for proof of
concept & a reference implementation.  I actually agree openssl
should not be a long-term dependency.  DH & RSA should not
require openssl.

I don't think this needs to depend on PKI.  It could, in the sense
that https does - but I don't see this as a necessary requirement.

rees> 
rees> 4. No special configuration required on the client
Maybe.

"Todd M. Lewis" <utoddl@email.unc.edu> writes:
utodd> What about old (which is to say, current) clients? Would a new server 
utodd> which has these capabilities mask suid for files it serves to old 
utodd> clients, or refuse to serve those files at all, or continue current 
utodd> behavior and hope for the best?

Respecting the SUID bit is 100% a decision the cache manager should
be making.  It should not be up to the file server to attempt to
enforce this.  Overall, my plan is:
	cells with old servers -- can only implement old behavior.
	cells with all new servers -- can support both old & new behavior.
	old (or none participating) clients -- see old behavior.
		"fs setcell" can be used to control old behavior.
	new clients with proper configuration -- see new behavior.

My intention was to only provide manual configuration.  That
is the sysadmin installing afsd on a client would have to
somehow acquire the correct public key for the cell & put it
in the right place -- and then restart the cache manager.
That file could be, /etc/openafs/certs/umich.edu .
This could be improved several ways, such as:
/1/ an "fs" command to cause afsd to rescan /etc/openafs/certs
	or to explicitly specify or change a public key
	for a given cell.  This could be like "fs newcell".
/2/ slightly more complicated automatic logic to ask a cell (at
	startup?  upon first reference?) if it has a public key
	and to store it away somewhere.
/3/ even more complicated logic to respect certificate authorities.

For medium to large scale environments which already distribute
their own custom CellServDB's, approach 1 (manual configuration) should
be sufficient.  Approach 2 approximates the security of DH - if it
retains the cell public key between reboots this probably approximates
the security most people actually get with ssh host keys.  This is
Jeff Altman's "leap of faith" security model.  Approach 3 involves
us with the one part of PKI that actually seems to work.

Jeff Altman writes:
jaltman> The group that developed the rxgk proposal spent a long time looking at
jaltman> the security requirements for AFS.
jaltman> 
jaltman>   http://www.afsig.se/afsig/space/rxgk-hackathon-2007/outline-rxgk.pdf
jaltman> 
jaltman> I'm posting the document instead of transcribing the text because the
jaltman> contents are color coded to indicate what can be fixed and what cannot be.
jaltman> 
jaltman> The rest of the rxgk content can be obtained from
jaltman> 
jaltman>   http://www.afsig.se/afsig/space/rxgk-hackathon-2007
jaltman> 
jaltman> Jeffrey Altman

Indeed, my proposal owes a lot to rxgk.

Ken Hornstein <kenh@cmf.nrl.navy.mil> writes:
kenh> For hosts I manage (e.g., the ones I really do care about priv
kenh> escalation issues) they already have an installed Kerberos keytab.
kenh> Some significant work would have to be done to make this usable by the
kenh> AFS client, but I don't see anything inherently insurmountable.  I'm
kenh> not saying a "trust the first connect" fallback isn't worthwhile, but
kenh> if you've already drank the Kerberos Kool-Aide one of the hard pieces
kenh> (the key distribution & management piece) is already done.

Yes, if the kerberos host key were there, it could be used.
It's not completely straight-forward; given that key,
it would be necessary to use it to acquire an afs service
key, then use additional goop to wrap the user ticket inside
of that.  There is a U-U mode in kerberos 5 that looks like
it could handle that, but I think it's enough different that it's
not useful.  I want the same user afs service ticket to work
both inside the cm token wrapper & without the wrapper, and
I don't think the U-U mode allows that.

I think the public key case is still necessary, because it accomodates
sites and environments where the host key might not be present or useable.
Using a kerberos host key outside of the local set of kerberos realms
is problematical.  Distributing kerberos host keys in a sufficiently
large environment (say, the UofM) especially on machines like laptops
is also a problem.

If I have to solve the public key case anyways, I'm not sure
the kerberos host key is then actually worth the extra work.

Adam Megacz <megacz@cs.berkeley.edu> writes:

megacz> This sounds really nice.  One concern, though: how is the user alerted
megacz> to this fact, and how does the user indicate "yes, it's okay to accept
megacz> a new server key" without root access on the client?  SSH has no
megacz> kernel component, so this sort of decision can be made individually by
megacz> each local user on the client.  For the CM it appears that the
megacz> decision would be made on a per-client basis, not a per-client-user
megacz> basis.

The cache manager and afsd can't meaningfully interrogate the user.
The "server key" here is global to the cache manager, it's not case by
case per user.  So, either the user is also root, in which case he can
fix things, or he's not root, in which case why would we take his word
on whether we should trust that key?  The way this would work for
"leap of faith" is that the CM would blindly trust the first public
key it acquires - and it *might* preferentially trust a different
public key if and only if the first one were acquired without
user credentials and the 2nd one were acquired with user credentials.
In all other cases, the only way the CM should choose a different
public key is if root goes in & tells it to stop trusting some old
public key, or if the public key itself were labelled with an
expiration date.

megacz> I think there's some confusion here about public-key *technology*
megacz> (algorithms such as RSA, DSA) and public-key *infrastructure* (CA's
megacz> and roles such as verisign's).  A good example of the distinction is
megacz> SSH, which uses the former but not the latter.
megacz> 
megacz> I don't think anybody is suggesting reliance on public-key
megacz> *infrastructure*.

In fact, with case /3/ above I am indeed suggesting PKI is possible.
I'm not requiring it however.  Case /1/ and /2/ don't require PKI,
but do use public key technology.  A notable example of PKI-lite is
the pgp "web of trust" scheme - which is interesting but probably
not quite useful here.

					-Marcus Watts