Re: [xri] XRD trusted discovery workflow

[Nat Sakimura <n-sakimura@nri.co.jp>]

Dirk Balfanz wrote:
>
>
> On Wed, Dec 10, 2008 at 9:13 PM, Nat Sakimura <n-sakimura@nri.co.jp 
> <mailto:n-sakimura@nri.co.jp>> wrote:
>
>
>
>     Dirk Balfanz wrote:
>
>
>
>         On Wed, Dec 10, 2008 at 5:54 PM, Brian Eaton
>         <beaton@google.com <mailto:beaton@google.com>
>         <mailto:beaton@google.com <mailto:beaton@google.com>>> wrote:
>
>            On Tue, Dec 9, 2008 at 8:35 PM, Dirk Balfanz
>         <balfanz@google.com <mailto:balfanz@google.com>
>            <mailto:balfanz@google.com <mailto:balfanz@google.com>>> wrote:
>            > - Both in the PKI and in the out-of-band versions the basic
>            verification
>            > step seems to go like this: you already have a
>         canonical_id, and
>            you do the
>            > following: (1) check that the canonical_id in the XRD
>         document
>            is the same
>            > as the canonical_id you're already holding, (2) verify the
>            signature on the
>            > document, (3) verify that the key used to sign the document
>            matches the
>            > canonical_id in the document. Why bother with the
>         canonical_id
>            in the
>            > document in the first place? Why not just (1) verify the
>            signature, and (2)
>            > verify that the key used to sign the document matches the
>            canonical_id
>            > you're already holding?
>
>            The canonical id in the document is important because it
>         prevents
>            someone from replaying a document in a different context.  For
>            example, imagine two users with two different XRDs:
>
>            http://www.example.com/good has a signon URL of
>            http://some-trusted-idp
>
>            http://www.example.com/evil has a signon URL of
>         http://some-evil-idp
>
>            Both XRDs are signed by www.example.com
>         <http://www.example.com> <http://www.example.com>
>
>            (which is what you'd expect
>            since they are authoritative for www.example.com
>         <http://www.example.com>
>            <http://www.example.com> URLs...).
>
>
>            Now imagine that some RP is looking for the XRD for
>            http://www.example.com/good, but an attacker substitutes
>         the XRD for
>            http://www.example.com/evil.
>
>            Without a canonical ID in the XRD, there's no way for the
>         RP to tell.
>
>     OK. I am starting to get it. You want to support a scenario where
>     www.example.com <http://www.example.com> is acting as
>     proxy/delegated signing authority for each user (e.g. good, evil).
>     In this case, there has to be a proof that these users actually
>     delegated the signing task to www.example.com
>     <http://www.example.com>. How do you propose to solve this? I do
>     not quite see how it is done in the current documentation.
>
>
>
>            (If this is coherent/accurate we need to write it down
>         somewhere,
>            because the attack is kind of subtle.)
>
>
>         Ah, I see.
>
>         So I think what's going on here is the following: Since we
>         don't have keys for http://www.example.com/good vs.
>         http://www.example.com/evil (we only have one key for
>         www.example.com <http://www.example.com>
>         <http://www.example.com>), www.example.com
>         <http://www.example.com> <http://www.example.com>'s key is
>         authoritative for both. If we had two different keys, then
>         this attack wouldn't be possible, right?
>
>     Indeed. And that is what I have been promoting. With it, you can
>     rely on PKI chain and it's done.
>
>
> Yes, I can see how that would work. 
>
> The problem is that we don't have certs that associate keys with URIs. 
> We only have certs that associate keys with domains.
Well, my example on wiki and the previous email caused some confusion, 
but I am envisioning a case that CanonicalID being not URI at all as 
well. It could be just SubjectUniqueIdentitifer or Subject of X.509 
certificate. To associate URI etc. to this certificate, we are using 
XRD. If the <CanonicalID> of the XRD is equal to Subject in X.509, they 
are linked.

The workflow is like this:

   1. When you access the Indentity URI, you will get link-header etc.
      that points to the XRD associated to it.
   2. When you look into XRD, you can find the URI for the cert.
   3. Retrieving the cert, do the usual cert check.
   4. Find the Subject(UniqueIdentifier) in the cert and compair that
      with CanonicalID.
   5. If they match, they are the pair we are looking for. See if the
      signature on XRD can be verified.
   6. If OK, the XRD is authoritative. You can trust it, and start using
      associated URIs (both in the authority section and services
      section) in it.

If we happen to want to reserve CanonicalID being a uri, then we can 
introduce something like <Subject> to the same effect.
>
> I think what Brian is trying to do is enumerate mechanisms that would 
> work today:
>
> (1) We do have an SSL PKI, so he gives a mechanism for that.
> (2) For people who aren't satisfied with the security provided by that 
> PKI (and you are pointing out some potential problems 
> here: http://lists.oasis-open.org/archives/xri/200812/msg00102.html) 
> he gives a mechanism for that, which is more painful (requires 
> exchange of keys, etc.), but if the delegator and delegatee agree, it 
> can also be done.
>
> I guess theoretically, we could add 
> (3) If CAs certify keys for URIs (which can never change), then there 
> is yet another (simpler) mechanism.
For this purpose, we can reuse the Subject or SubjectUniqueIdentifier 
field, IMHO.
Of course, if CAs start supporting the scenario (3), I am more than 
happy, but we do not have to wait for it.
>
> But that's a big "if" there - we can't assume that CAs will really do 
> that, certainly not in the short term. So (3) can't replace (1) or 
> (2), it can at most be a third choice, perhaps one that might work at 
> some point in the future.
>
> Dirk.
>