Skip to content. | Skip to navigation

Personal tools

Navigation

You are here: Home / Wiki / Gid

Gid

The GID

The GID

Design notes regarding the ProtoGENI GID, which may not be identical to a full GENI GID. Note that many of the discussions, etc. that went into this design work are linked from the bottom of this page.

Underlying Assumptions

  • All entities that wish to participate in the GENI API have GIDs
  • The GID is relative small, and constant size - probably around 128 bits
  • A GID is not enough to authenticate with by itself - it's an identifier.
    • To authenticate, you have a certificate, traceable back to some root authority, that associates a public key with your GID
  • We will use standard SSL mechanisms for revocation (though we may have to roll our own method for distributing the actual CRLs)
  • For the prototype, there will be a small, fixed set of trust anchors

Design Alternatives

The three big questions:

  • Who can generate certificates for a given GID?
  • How big is the "trusted base" of authorities that can issue GIDs/certificates, and how much do we trust them?
  • Can there be more than one certificate bound to a particular GID (possibly serially, not in parallel)?

GID a Certificate

The idea: An entity's GID is a certificate binding a UUID to a public key

Pros:

  • It's what is currently in the GENI docs, so is most likely to be inter-operable with other implementations
  • Self-certifying

Cons:

  • The certificate includes an expiration date, and if we were to renew a certificate by creating one with a later expiration date, this would constitute the creation of a new identity, unrelated at an architectural level to the previous one.
  • It also ties identity strongly to the authority that has signed the certificate - ie. if my institution signed my GID, and I change institutions, I have to get a new identity (or my old institution must continue vouching for my identity.)
  • If an entity needs to change its public key for any reason - ie. a real or suspected compromise of its private key, this also requires a new identity.

Rob says:

There are plenty of best-practices reason I might want to change keys. Obviously if my private key is compromised or lost, I need to change it, but there are many reasons short of these I might want to change my keypair. We change passwords routinely in case they've been compromised and we don't know it. If someone breaks into my machine, no matter what the vector, I change my passwords and ssh keys just in case. By tying identity and authentication, we (strongly) discourage GENI users from using these best practices, which doesn't seem like a good idea.

This feels to me kinda like making my UID = my password hash: it just doesn't seem like a good idea.

GID as Hash of Public Key

The idea: An entity's GID is the hash of its public key

Pros:

  • It's what is currently in the GENI docs, so is most likely to be inter-operable with other implementations
  • Self-certifying: because the GID is generated from the public key, anybody can generate a certificate for a given GID, but only someone who hold the matching private key can actually use it. This keeps it safe from misbehaving/compromised authorities
  • Transferrable: If someone moves to a different authority (say, a different institution), they can get a certificate for the same GID from their new authority

Cons:

  • If you want to change the private key (stolen, best practices, etc.), you have to get a whole new GID, and thus whole new identity (including new slices, etc.). In addition, the state of any delegations you have made with your old GID are in question. Are they still valid? Probably not since your GID no longer exists.

GID as UUID

The idea: An entity's GID is a locally created but universally unique string of bits that never changes. A UUID is defined in RFC4122.

Pros:

  • Your identity never changes, just the binding of the public key.
  • A user can have multiple keys bound to his identity. When a new key is issued for a user, it is then optional as to whether the old key has to be revoked.
  • Revocation in general is easier.

Cons:

  • Not self-certifying, so we have trust the entities that generate GIDs, or demand that we have the root certificates in our cache for all entities that we trust to make GIDs. If a certificate is not signed by one of those trusted roots, we do not trust the GID. We also discussed some alternatives to this, which use some of the bits to encode each trusted entity. I seem to have misplaced the details. Rob?
  • Technically not transferable since part of the UUID encodes the node on which the UUID was created. However, I think we can finess this issue.

GID as Self-Certifying Authority Chain

From:   ricci@cs.utah.edu
Subject: Re: GGIDs
Date: April 5, 2008 8:34:40 PM PDT
To:   stoller@flux.utah.edu
Cc:   geni-dev@flux.utah.edu


Imagine this. Someone from the testbed project in Emulab makes you a
GID, which is a UUID, and let's say it's 42. You now get a certificate
that says 'Emulab/testbed says GID 42 belongs to the person with this
public key', and you use that to authenticate yourself to a CM, since
you hold the private key that goes with that public key.

But now, project bar on Emulab decides it wants to impersonate you, so
it makes a new certificate that says 'Emulab/bar says GID belongs to the
person with this other public key', then presents GID and the new
certificate to a CM. There's no way at all to tell which one is the
'real you'.

Now, when there is only a single trusted entity issuing GIDs and the
associated certificates, we don't really have to worry about this. So,
we *might* be able to get away with it for the prototype, but it's
definitely not an option for GENI itself.

Making the GID a hash of your public key fixes this, because when
project bar goes to generate the bogus certificate, one of two things
will happen:
1) The public key it includes will not hash to the GID, so it'll be
    obvious that it's a bogus certificate
2) It will use your actual public key, in which case, it won't know the
    private key, so the bogus certificate will do no good (if it did
    know your private key, there would be no point in generating a new
    certificate)

Source Material

This documents some of our discussions, etc. on this topic.