1 Back in March we started a discussion of how we'd handle trust anchors
3 It didn't get very far.
5 The basic problem is that we need to establish trust in the identity
6 server corresponding to a NAI. We don't want to send our password to
7 some random attacker; we only want to send it to our identity server we
8 have a trusted relationship with.
10 There are a number of ways we can do this:
12 1. We can do certificate path validation. This is what web browsers
13 do. There is some set of trust anchors; we construct a path from the
14 root certificate to the certificate of the identity server. We also need
15 to confirm the name of the identity server somehow. So, we'd need:
17 * Set of trust anchors
18 * Constraints on subject name of server
19 * Constraints on subject alternative name of server
21 2. We can store a hash of the server certificate. This is nice and
22 simple: we simply need a 64-byte string.
24 3. Leap of faith. We can blindly send the password the first time we
25 connect to the identity server but then only connect to that identity
26 server again. This is roughly what ssh does.
29 Our goal is to optimize for the situation where we're getting
30 configuration information from those running the identity
31 server. However we also want a secure experience when a user is creating
32 an identity card themselves or an application is supplying an identity.
35 ### Where do we get trust anchors
37 Before understanding the tradeoffs between these three approaches we
38 need to look at how we would get trust anchors if we choose to do
39 certificate validation.
40 There are a number of options:
42 * we have a system-wide global default. This is easy to code but tends
43 to be quite bad from an operational/security standpoint.
45 * We get a trust anchor from the identity provider itself. It's unclear
46 what to do in the case where the user adds the identity
47 * We ask the user to select a trust anchor. It's possible to do this,
48 but it's really worse than any other option so not worth spending a
51 Note that deciding how identity providers need to be named is tricky if
52 we have a system set of trust anchors. EAP implementations haven't been
53 very consistent on this point.
57 * Leap of faith tends to be easy for users
59 * We would have to significantly extend the libeap code to implement
62 * Leap of faith tends to create support and operational complexity when
63 a server needs to change keys.
65 * Certificate validation with system trust anchors tends to create
66 operational and support complexity all the time
68 * Storing a certificate hash tends to create operational complexity if
69 there is not an update mechanism when servers need to rekey
71 ## What needs to represent a trust anchor on an ID card
73 * An optional base64-encoded CA certificate (a relatively long base64 string)
74 * An optional subject name constraint (string)
75 * An optional subject alternative name constraint (string)
76 * An optional hash of a server certificate
78 The server certificate hash field is mutually exclusive with the other fields.
83 * Support provisioning a server cert hash and a trust anchor+name
84 constraints in the identity provisioning format
86 * Use the system trust anchor store for user-provisioned identities and
87 do something about naminge
89 ## User Web Provisioning Format
92 <display-name>Unique Name</display-name>
93 <user>user_name</user>
94 <password>ENCRYPTEDPW</password>
95 <realm>issuer name</realm>
97 <service>xmpp@jabber.project-moonshot.org</service>
98 <service>email@project-moonshot.org</service>
102 <pattern>PATTERN</pattern>
103 <always-confirm>true</always-confirm>
106 <pattern>ANOTHER_PATTERN</pattern>
107 <always-confirm>false</always-confirm>
111 <ca-cert>ABCDEFGHIJKLMNOPQRSTUVWXYZ123455678910</ca-cert>
112 <subject>Foo</subject>
113 <subject-alt>Bar</subject-alt>
114 <!-- Or alternatively -->
115 <server-cert>ABCDEFGHIJKLMNOPQRSTUVWXYZ123455678910</server-cert>
119 <display-name>Another Identity</display-name>
120 <username>another_username</username>