Re: [cwg] Problems with the GID

> These are some notes about the GID (aka the GGID) as it's currently
> defined in the architecture documents (eg. GDD-07-44). As we've tried to
> implement a prototype of a GID as part of Utah's ProtoGENI project, we
> run into some things that we think make the GID, as currently specified,
> unworkable. My goal in sending this mail is to get a discussion of these
> issues started, possibly ending up with a revised definition of the GID,
> or at the very least, a clarification of the existing definition.
>
> Much of the content of the discussions at Utah that have lead us to
> these conclusions are available here:
>
>     http://www.protogeni.net/trac/protogeni/wiki/GID
>
> The design documents currently state that a GID is a certificate binding
> a UUID to a public key - thus, the identities of users, slices,
> component managers, etc. are certificates.
>
> The main advantage of this is that it makes identity self-certifying:
> giving another party a GID is, by itself, enough (along with some
> standard cryptographic challenge) to "prove" that the entity supplying
> the GID holds the private key that matches the certificate, and thus
> "is" the entity the GID belongs to.
>
> There are a number of problems with using a certificate as an identity,
> however. An example of this is that the certificate includes an
> expiration date,

> 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.) Finally, 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. When
> entities are users, and they store keys, etc. on desktops and laptops,
> this is not an uncommon operation. Because many objects and rights in
> GENI will be tied to GIDs (eg. rights to create and control slices, the
> slices themselves, tickets, etc.), having to change a GID is a pretty
> big deal.
>
> The design documents don't make the purpose of the UUID in this clear,
> but it seems that it was intended to be the "real" identifier - ie. in
> any of the above situations, I would obtain a new certificate, possibly
> from a different authority, and possibly with a different public key,
> but with the same UUID. If this is the case, I'd argue that the GID is
> misleadingly misnamed - it's not an identifier at all, it's simply a
> certificate used for *authenticating* an identity.  Thus, in the rest of
> the documents, when we refer to, say, issuing a ticket to a specific
> slice, the identifier to which that ticket is bound should be the
> slice's UUID, not a particular certificate.  Similarly, when delegating
> rights to control (eg. stop) a slice, the delegate and slice should be
> specified as UUIDs. This makes the identity itself relatively permanent,
> while attestations as to that entity's public key (certificates) may
> change, be revoked, etc.
>
> Using a UUID as identifier rather than a certificate solves the problems
> listed above, but loses the property of self-certification.  To a first
> approximation, this seems okay: when an entity wants to talk to another
> entity via the GENI API, it supplies both its UUID and a certificate
> binding this to a public key. This looks very much like it did before,
> with the distinction that it's the UUID and not the certificate that is
> the identifier. At different times, an entity with the same UUID might
> use a different certificate to authenticate itself, but with the
> understanding that it is still the "same" entity.  (We'll need a
> certificate revocation mechanism, but we would need that anyway.)
>
> It also loses another property, though, that might be a bigger problem:
> the binding between UUID and public key is no longer unforgeable. With
> certificate-as-identifier, one cannot impersonate another entity short
> of stealing their private key (or tricking them into using it, etc.) If
> one were to try to make a new certificate with a different public key in
> it, it would be considered a new identity, and thus not succeed as an
> impersonation attempt. If the identifier, however, is simply a UUID,
> there is nothing to stop an authority unrelated to the entity from
> issuing a certificate binding its UUID to another public key. Thus, a
> researcher from institution A with UUID X and public key K may be
> impersonated by institution B: it simply needs to sign a certificate
> binding UUID X to public key J.
>
> Essentially, a flat UUID does not "belong" to any issuing authority, and
> thus any authority can bind it to a public key. This means that once one
> trusts an authority (which may be a root, such as GENI itself, or may
> derive authority from the root, such as an institution that has has been
> authorized by GENI to create users) to bind UUIDs to public keys, that
> authority has the ability to bind a public key to *any* UUID, a power
> that it can use for good (to help the entity authenticate) or evil (to
> impersonate the entity "improperly"). It looks to me like the GENI
> architecture expects there to be a relatively large number of
> authorities trusted to create GIDs (probably deriving their authority
> from a fairly small number of roots). So it doesn't seem like this is a
> power we should be willing to give all of them.
>
> One way to fix this is to somehow "partition" the UUID space, so that
> some of the bits are used to identify the issuing authority, in a way
> that is verifiable.  This limits the scope of each authority to UUIDs
> that it has issued, and allows more flexible policy with respect to
> trusting authorities (ie. I might trust the global GENI authority to
> assign public keys to any user at all, but I might only trust Utah to
> bind public keys to UUIDs within its own space). It does, however, tie
> an identity to the authority that originally issued it, so one cannot
> "move" and identity from one authority to another, so it's missing one
> of the desirable properties. So, I'd be interested in hearing
> alternatives that would preserve this property.
>