Re: Questions reg. XKMS spec

Hi Stephen, 

Thanks for your reply,

On 5/18/05, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
 
> > The KeyBindingAbstractType allows for 0 UseKeyWith elements.
> > Does that mean that it is allowed to issue a query for a keybinding
> > matching a particular value of a key?
>
> Yes. Though given that you somehow got the key already I'm not sure
> why you're doing a locate, but I can imagine justifications. Do you
> have a realistic application doing this or is it just a corner-case?
> 

The attacker has *a key*, but does not know how to use it... (see below)

I don't have an app that uses this feature, I'm just trying to
understand the ideas behind the specification. ;)


> > Does this not pose a security threat (although a practically ignorable one)?
> > An attacker can generate a key and let an XKMS service "do the hard
> > work" of trying to find a matching target. I know the probability of
> > success is equal to a brute force attack, but the difference (as I see
> > it) is that this allows the attacker to relay the "key search work"
> > to the XKMS service provider.
> 
> This is no different from other PKI-based DoSes, e.g. sending in a


Actually I wasn't thinking DoS. The scenario I thought of was this:

1) Attacker generates random private/public keypair, that is fairly
useless on its own.

2) Attacker sends a Locate request containing the public key to an XKMS service

3) There is a 1/<huge number> probability that the XKMS service has a
keybinding with the same keypair, BUT if it does

4) the XKMS service will respond with information identifying the
target, signed public key certificates and certificate chain.

5) Now the attacker has a keypair, AND a lot of information about who
else uses the keypair and he is now ready to forge signatures, decrypt
secret stuff, register keys under fake ID etc.

So he does not use XKMS to discover a key, but to discover an identity
that is bound to the keypair he already has. Chances of success are
diminutive at best, but the attack is really simple and easy to
perform - just make a key, and ask around if anybody else uses the
same key.

But, as you say, when developing an implementation of an XKMS service,
it is easy to make it /not do/ this kind of search, unless there is
some scenario where such a search would actually be useful (search
based *only on keyvalue*).
Can't think of a meaningful one though... 

  
> > Question 2)
> > Para 222 says that when invoking a Locate service, a Keybinding
> > matches the query, if:
> >     *  The key binding contains all the <UseKeyWith> elements
> > contained in the query, and
> >     *  The key binding contains all the <KeyInfo> elements contained
> > in the query.
> > What about the KeyUsage element? If the query is for a key for
> > signature verification, then returning an encryption key is of no use?
> > Is the KeyUsage neglected because some major PKIs don't
> > support/implement attributes corresponding to this?
> > Actually, in Para 176 it says:
> > "If a key usage is specified in a QueryKeyBinding however the key
> > usage forms part of the criteria the service should attempt to match."
> >
> > (-and in my implementation KeyUsage IS significant for Locate operations :-)
> 
> Can't remember! However, given recent discussion on PKIX about
> mis-uses of their key usage bits, maybe this was a clever thing
> to do:-)

OK. I can't say that I know of the discussion you refer to, but if
keyusage can be misused, it is of course a good reason to ignore it in
searches. Still P222 and P176 seem a little contradictory. ;)

 
> > Question 3)

> I've called this a kind of blood-brain barrier in the past,
> where we don't allow any X.509 specific PDUs get directly
> represented in the xkms protocol.

Makes perfect sense.


Thanks for your reply.

---
Cheers,
Kenneth Ahn Jensen

Received on Wednesday, 18 May 2005 15:30:40 UTC