Notes about SFS and UIA as Related Work

Date: Mon, 14 Apr 2008 15:58:15 -0600
From: Robert P Ricci <ricci@cs.utah.edu>
Subject: Re: GGIDs

The technical manner in which SFS and UIA do self-certification is
roughly equivalent to what is in the GENI docs about GIDs (GID = hash of
pub key.) Both have the problem of compromised private keys requiring
new identities, but the threat models are a bit different.

For SFS, it's the server keys that matter, so the security model is a
bit different - we normally assume users are much more likely to lose
their private keys or have them compromised than 'service providers'
(ie. fileservers or CMs). So, key compromises are likely to be more
rare. Also, because everything is self-signed (ie. no CAs), there is no
hierarchy, and thus there's no equivalent of compromising the private
key Emulab uses to sign users or project's GIDs. Obviously, in the
GENI/pGENI case, we *want* some central authorities, because otherwise,
anybody can make up new users.

In UIA's case, the case is more complicated.  Essentially, it's devices
have have identities, not users: the closest thing there is to a user
identity is that user makes a 'group' of his/her devices. If the private
key of a device is compromised, you would have to give that device a new
identity. 'Groups' do *not* have EIDs, which are the self-certifying
things (I'm 90% sure, but am not finding a succinct statement of this in
the paper.) So, they can have a more complicated protocol for handling
key compromise in case one of the 'owning' devices is lost/stolen.

From: Leigh Stoller <stoller@flux.utah.edu>
Subject: Re: GGIDs
Date: Mon, 14 Apr 2008 15:07:28 -0700

SFS seems closer to GENI then I first thought; it aims to   
decentralize control of the namespace (file servers that can
participate) and allow them to certify themselves without a central
authority.

Is it possible that representing components (servers) and users with
the same mechanism is the root cause of our problems?

Date: Mon, 14 Apr 2008 16:26:01 -0600 
From: Robert P Ricci <ricci@cs.utah.edu>
Subject: Re: GGIDs

Thus spake Leigh Stoller on Mon, Apr 14, 2008 at 03:07:28PM -0700:
> SFS seems closer to GENI then I first thought; it aims to  
> decentralize control of the namespace (file servers that can  
> participate) and allow them to certify themselves without a central  
> authority.

I think we want more control over the namespace than SFS does -
basically what they want is anarchy, in which anyone can generate their
own valid identifier. What we want is certainly decentralized, but more
strucutred - we want to be able to tell that someone is a real pGENI
user because they can trace their identity back to a trusted root. Both
do want to be able to *authenticate* without talking to the central
authority, which is the main similarity, and why we are talking about
self-certifying identifiers in both cases.

> Is it possible that representing components (servers) and users with  
> the same mechanism is the root cause of our problems?

I don't think so - see my comment about CM URLs in my other message.

Date: Mon, 14 Apr 2008 16:10:39 -0600      
From: Robert P Ricci <ricci@cs.utah.edu>
Subject: Re: GGIDs

Thus spake Leigh Stoller on Mon, Apr 14, 2008 at 03:00:02PM -0700: 
> The interesting thing about SFS is that is uses self certifying   
> pathnames so that clients can verify the servers. The pathname is an  
> sha1 hash of the hostname and the host's public key. That is, the  
> hostname stays the same even if the private key has to change for  
> some reason. For those who forgot, in SFS a self certifying pathname  
> is hostname:hostid/foo/bar where hostid is the hash mentioned above.

While it's true that the hostname stays the same, the 'identity' of the
host *does* change if you have to change its public/private keys. All
paths you had to files on that server are now invalid.

In the GENI case, the URL to the CM could similarly not change if you
changed the GID - it's just that the URL is not part of the 'identity'
in a GID.

From: Leigh Stoller <stoller@flux.utah.edu>
Subject: Re: GGIDs
Date: Mon, 14 Apr 2008 15:22:44 -0700

>While it's true that the hostname stays the same, the 'identity' of  
>the
>host *does* change if you have to change its public/private keys. All
>paths you had to files on that server are now invalid.

SFS encourages symlinks to avoid this problem, but I see your point.

>In the GENI case, the URL to the CM could similarly not change if you
>changed the GID - it's just that the URL is not part of the 'identity'
>in a GID.

I don't quite parse the above, but it seems to me that the SFS
equivalent is that the URL is hashed with the public key to give you
URL:hash/foo/bar or rather URL/hash/foo/bar ...

But, lets go back a message to my concern about using the same
mechanism for components and users. I think SFS assumes that servers
rarely have to change their host keys (and thus the path), and I
would say the same would be true of GENI components.

Users are different. I think it is much more likely that users will
have to change their keys.
What if users were represented as stoller.emulab.net:hash where hash
is the hash of stoller.emulab.net and my public key?

Date: Mon, 14 Apr 2008 16:44:59 -0600
From: Robert P Ricci <ricci@cs.utah.edu>
Subject: Re: GGIDs

Thus spake Leigh Stoller on Mon, Apr 14, 2008 at 03:22:44PM -0700:
> >While it's true that the hostname stays the same, the 'identity' of  
> >the
> >host *does* change if you have to change its public/private keys. All
> >paths you had to files on that server are now invalid.
> 
> SFS encourages symlinks to avoid this problem, but I see your point.

Right, this is basically adding a layer of indirection. Did you see my
mail on the geniarch list about slice revocation, in which I
hypotehsized that if you can keep the same human-readable name for a
slice even if you have to change the GID, this is acceptable? This is
basically the same thing.

> But, lets go back a message to my concern about using the same  
> mechanism for components and users. I think SFS assumes that servers  
> rarely have to change their host keys (and thus the path), and I  
> would say the same would be true of GENI components.

Yep, I agree. But all of our problems have been because we have weaker  
assumptions about how 'safe' users are, and I would think if we come up
with something good enough to statisfy these weaker safety assumptions, 
it should be good enough to handle the stronger assumptions of safety we
have for CMs.

> Users are different. I think it is much more likely that users will  
> have to change their keys.
> What if users were represented as stoller.emulab.net:hash where hash  
> is the hash of stoller.emulab.net and my public key?

This by itself is not quite enough - we also have to verify that the
entity that issued the certificate for you is 'authoritative' for
emulab.net, or assume that only a small, trusted set of entities can
issue GIDs. (This goes back to our discussion last week.)

Keep in mind, though, that you are still changing your identity when you
change keys.