Meeting-Notes-20080422

Today's (04/22/08) discussion (with Jay, Rob, Leigh, Mike, Dave present) on authentication centered on the decision to not use the hash of the public key (also called self-certifying identity) as the identity for a user, and in general anything with a GID.

The advantages of self-certifying identities (see SFS) are that two parties can authenticate each other without any third party help (such as a list of CAs who sign the keys).

The classic problem though is that changing your public key changes your identity, which we feel is bad. Some reasons:

• Makes it hard to keep historical data (ie. archive experiment results)
• Forces tearing down existing slices, which might not really be necessary
• Have to run around getting credentials, tickets, etc. again

Part of the threat model here is that things that are in the hands of users (researchers) are fairly vulnerable - desktop machines get compromised all the time, and if you even suspect that your private key has been compromised, you should change it. SAs and other "root" entities keys may also bee compromised, but the occurrence of this is expected to be lower. If users need to hold onto keys for their slices, the same problems apply to slice GIDs as to user GIDs.

The traditional solution is a centralized lookup (table) to map onto true identities, or to look up the public key for a particular identity, but this also has potential downsides; a remote operation anytime a GID need to be mapped to its true identity. In a highly distributed environment such as GENI this could cause operations to fail or be delayed. It also cancels out the main advantage of self certifying identities, which is that no third party is needed.

The alternative is to use the UUID (placed inside the x509 certificate) to identify users, but otherwise allow the regeneration of the public key. The problems with this approach are:

• Anyone can generate a public with someone else's UUID and pretend to be that other person, for certain operations.
• Even trusted peers cannot truly be trusted, although the threat here is more likely bugs in the software, but also the possibility of malicious behavior.
• Regenerating the public key caused any credentials or tickets in play to become a problem. Are they automatically invalid, or are they okay until actively revoked? For an active slice (with slivers) revoking the old key would make it impossible for the original user to control (terminate) those slivers)

Rob came up with an approach to solve the impersonation problem; use part of the UUID bit space to encode which site has issued the UUID. For example, the upper bits would be set to XXX for any UUID issued by Emulab, YYY for any UUID issued by Kentucky, etc. This would make it impossible for another site to issue a UUID that impersonates a user at another site.

Of course the ssl handshake will not verify this requirement, so it needs to be done afterwards in the server code and in any code that contains public keys (tickets, credentials). Is this a potential problem?

Regarding un-mediated delegation of capabilities; I think that the above approach still allows for un-mediated delegation of capabilities, but need to think about this more.