design/trust-anchor.mdwn

   1 Back in March we started a discussion of how we'd handle trust anchors
   2 for the project.
   3 It didn't get very far.
   4
   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.
   9
  10 There are a number of ways we can do this:
  11
  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:
  16
  17   * Set of trust anchors
  18   * Constraints on subject name of server
  19   * Constraints on subject alternative name of server
  20
  21 2. We can store a hash of the server certificate. This is nice and
  22 simple: we simply need a 64-byte string.
  23
  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.
  27 ### Our goal
  28
  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.
  33
  34
  35 ### Where do we get trust anchors
  36
  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:
  41
  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.
  44
  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
  49   lot of time on.
  50
  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.
  54
  55 ### Tradeoffs
  56
  57 * Leap of faith tends to be easy for users
  58
  59 * We would have to significantly extend the libeap code to implement
  60  leap of faith
  61
  62 * Leap of faith tends to create support and operational complexity when
  63  a  server needs to change keys.
  64
  65 * Certificate validation with system trust anchors tends to create
  66   operational and support complexity all the time
  67
  68 * Storing a certificate hash  tends to create operational complexity if
  69   there is not an update mechanism when servers need to rekey
  70
  71 ## What needs to represent a trust anchor on an ID card
  72
  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
  77
  78 The server certificate hash field is mutually exclusive with the other fields.
  79
  80
  81 ## An option
  82
  83 * Support provisioning a server cert hash and a trust anchor+name
  84   constraints in the identity provisioning format
  85
  86 * Use the system trust anchor store for user-provisioned identities and
  87   do something about naminge
  88
  89 ## User Web Provisioning Format
  90     <identities>
  91       <identity>
  92         <display-name>Unique Name</display-name>
  93         <user>user_name</user>
  94         <password>ENCRYPTEDPW</password>
  95         <realm>issuer name</realm>
  96         <services>
  97           <service>xmpp@jabber.project-moonshot.org</service>
  98           <service>email@project-moonshot.org</service>
  99         </services>
 100         <selection-rules>
 101           <rule>
 102             <pattern>PATTERN</pattern>
 103             <always-confirm>true</always-confirm>
 104           </rule>
 105           <rule>
 106             <pattern>ANOTHER_PATTERN</pattern>
 107             <always-confirm>false</always-confirm>
 108           </rule>
 109         </selection-rules>
 110         <trust-anchor>
 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>
 116         </trust-anchor>
 117       </identity>
 118       <identity>
 119         <display-name>Another Identity</display-name>
 120         <username>another_username</username>
 121       </identity>
 122     </identities>