OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xri] XRD trusted discovery workflow




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.
>
> 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.
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]