From 7dcce2c9600e41b3e651c1035b856e3f3150ead4 Mon Sep 17 00:00:00 2001 From: Sam Hartman Date: Tue, 21 Jun 2011 19:09:04 -0400 Subject: [PATCH] Add trust anchor discussion --- design/trust-anchor.mdwn | 78 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 design/trust-anchor.mdwn diff --git a/design/trust-anchor.mdwn b/design/trust-anchor.mdwn new file mode 100644 index 0000000..d2dfdf2 --- /dev/null +++ b/design/trust-anchor.mdwn @@ -0,0 +1,78 @@ +Back in March we started a discussion of how we'd handle trust anchors +for the project. +It didn't get very far. + +The basic problem is that we need to establish trust in the identity +server corresponding to a NAI. We don't want to send our password to +some random attacker; we only want to send it to our identity server we +have a trusted relationship with. + +There are a number of ways we can do this: + +1. We can do certificate path validation. This is what web browsers +do. There is some set of trust anchors; we construct a path from the +root certificate to the certificate of the identity server. We also need +to confirm the name of the identity server somehow. So, we'd need: + + * Set of trust anchors + * Constraints on subject name of server + * Constraints on subject alternative name of server + +2. We can store a hash of the server certificate. This is nice and +simple: we simply need a 64-byte string. + +3. Leap of faith. We can blindly send the password the first time we +connect to the identity server but then only connect to that identity +server again. This is roughly what ssh does. +### Our goal + +Our goal is to optimize for the situation where we're getting +configuration information from those running the identity +server. However we also want a secure experience when a user is creating +an identity card themselves or an application is supplying an identity. + + +### Where do we get trust anchors + +Before understanding the tradeoffs between these three approaches we +need to look at how we would get trust anchors if we choose to do +certificate validation. +There are a number of options: + +* we have a system-wide global default. This is easy to code but tends + to be quite bad from an operational/security standpoint. + +* We get a trust anchor from the identity provider itself. It's unclear + what to do in the case where the user adds the identity +* We ask the user to select a trust anchor. It's possible to do this, + but it's really worse than any other option so not worth spending a + lot of time on. + +Note that deciding how identity providers need to be named is tricky if +we have a system set of trust anchors. EAP implementations haven't been +very consistent on this point. + +### Tradeoffs + +* Leap of faith tends to be easy for users + +* We would have to significantly extend the libeap code to implement + leap of faith + +* Leap of faith tends to create support and operational complexity when + a server needs to change keys. + +* Certificate validation with system trust anchors tends to create + operational and support complexity all the time + +* Storing a certificate hash tends to create operational complexity if + there is not an update mechanism when servers need to rekey + + +## An option + +* Support provisioning a server cert hash and a trust anchor+name + constraints in the identity provisioning format + +* Use the system trust anchor store for user-provisioned identities and + do something about naming -- 2.1.4