Re: [xri] XRD trusted discovery workflow

[Dirk Balfanz <balfanz@google.com>]

On Wed, Dec 10, 2008 at 9:13 PM, Nat Sakimura <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>> wrote:

   On Tue, Dec 9, 2008 at 8:35 PM, Dirk Balfanz <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>

   (which is what you'd expect
   since they are authoritative for 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 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. 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>), 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. 

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. 

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.

 

But since we only have one key (the one for www.example.com <http://www.example.com>), that key needs to play both roles, and it needs to be able to tell us whether its used as the .../good signing key or the .../evil signing key. That makes sense. Is the CanonicalID the appropriate field to say that convey that information, or are you piggy-backing new semantics on an otherwise-defined field?

I do not think <CanonicalID> is the right one.
There needs to be an explict statement that the Subject identified by CanonicalID has delegated the signing to www.example.com.

=nat

Dirk.