[Cryptography] Transparent remote file access

[Nico Williams]

On Mon, Nov 27, 2017 at 10:59:27AM -0500, Phillip Hallam-Baker wrote:
> Kerberos solved some of these problems of course. But a Kerberos KDC has
> absolute God level privileges to achieve that. If the KDC is ever
> compromised you are hosed. Mallet is my sysop, I don't trust him. If I use
> a KDC based on symmetric crypto, I give Mallet root access to everything.

Kerberos should really be updated to support (EC)DH for all exchanges,
with static service public keys plus forward security via an ephemeral
public key for both, the client and the service.  This would greatly
limit what a KDC operator could do, though they could still impersonate
users and services (just like Certification Authorities in PKI).  Add a
PAKE for initial credential acquisition and recovery from KDC compromise
can be quite simple.

This way Kerberos would be a lot like PKI, really, with short-lived
tickets (as compared to, in a PKI, fresh or non-fresh certificates, and
possibly fresh OCSP Responses, stapled or otherwise).

There's a great duality between Needham-Schroeder and PKI.

Needham-Schroeder, of course, is post-quantom if you use sufficiently
large symmetric keys.  Adding (EC)DH could be done in a way that does
not weaken the PQ nature of Needham-Schroeder (except maybe when
recovering when a KDC compromise).

On the other hand, all hierarchical systems fail the same way that the
web PKI did: politically/commercially you can't have one root.  DNSSEC
is the one exception so far, and perhaps we could use DNSSEC to
bootstrap cross-realm trusts in Kerberos, but this would be done with
PK, so there goes the PQ...

Although, given slow, big-keyed PQ PK, Needham-Schroeder could be a
useful way to amortize the cost of such PQ PK.  I wouldn't count
Kerberos out just yet.

But enough with that digression.

> What I want is to address scenarios such as the following without any
> password based credential whatsoever. There might be a PIN to unlock a
> private key but I don't want any password based credential or proof of
> knowledge of a password to go on the wire.

Kerberos does have PKINIT, which you can use with a token.

> *Scenario 1:*

Q1:  Do you trust the file server(s)?  If so, why?

If you don't, then you should be using them only as object stores, doing
all file content (and directory) crypto in the client, using encryption
to users/groups via PK.  You don't need a particularly smart file server
for this.  But you do end up having to trust the clients a fair bit to
operate correctly, otherwise bad things can happen.

See Lustre for an illustration of the complexities of distributed
filesystems where the clients play a central role in correctness.

Alternatively, if you centralize all the metadata operations then the
server will have a lot more information for traffic analysis, even if
you encrypt actual file data on the clients.

> *Scenario 2:*
> 
> Alice writes a cron job to run at a particular time to perform an
> operation on a particular set of files. on Machine 1.
> 
> In this case, the machine has sufficient data to compromise the data
> hosted. But the data should be secure if someone with physical access
> takes the disks.

You can always encrypt to public keys...

> What I am looking for is not necessarily cryptographic enforcement of
> the access controls. When faced with an insider threat, it is pretty
> much inevitable that the data on that particular host is going to be
> hosed if a user loads it into the memory space of some application.

Sure.

> But looking at recent attacks, I am seeing that a LOT of the threats
> we are facing are coming from sideways contamination. The Russians
> attacked thirty DNC staffers with phishing emails, they only
> compromised one and not the machine that they were after. But once
> they were past the firewall, they could hop from one machine to the
> next without difficulty.

Preventing privilege escalation is extremely difficult.  You need lots
of isolation, not just in terms of processes, kit, and networks, but at
the organizational level too.

Nico
--