Re: Questions reg. XKMS spec

Hi Kenneth,

Kenneth Jensen wrote:

> Hello,
> 
> I am currently finishing a thesis project centered around XKMS, and I
> have a few questions, that I didn't know where else to ask than here,
> although I am unsure if this is a "public" list.

Yes, this is the correct public place to ask these questions.

> 
> Question 1) 
> When a Locate service "locates" keybindings, it must match on elements
> in the KeyInfo and the UseKeyWith (and KeyUsage) elements in the
> QueryKeyBinding.
> 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?
(I can well imagine asking about a KeyName.) A validate based on a
KeyValue however, is eminently sensible.

However, I wouldn't expect many responders to operate this way,
so having an application depend upon just this form of query
is probably a bad idea (as would having an application that only
ever sends in key names).

 > Example (simplified):
> 
> <QueryKeyBinding>
>   <KeyInfo>
>      <RSAKey>
>         <Modulus>123</Modulus>
>         <Exponent>456</Exponent>
>      </RSAKey>
>   </KeyInfo>
>   <RespondWith>Everything, please</RespondWith>
> </QueryKeyBinding>
> 
> 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
phoney x.509 cert with an LDAP URI that hangs the responder for
a socket timeout. Or sending in some kind of wildcard KeyName
or something.

I see three general ways you might handle this: 1) only do
this in two-phase mode, b) force client authentication before
expending too much CPU, and/or c) include anti-DoS heuristics
in your responder to react to potentially malicious queries.
A commercial-grade responder should probably do all three
really.

> 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:-)

> Question 3) 
> There are 3 values for KeyUsage defined, Encryption, Signature and KeyExchange.
> I am missing an option for intermediate certificate authorities. Is
> that left out on purpose? (and if so, may I ask the arguments for
> doing so?) If it is not there, either the value "Signature" can be
> interpreted as implying "signing certificates", or one will have to
> implement a non-compliant value. I see a practical value of being able
> to register CA's (off course not for root-certificates), but maybe I
> am missing some point.

This is deliberate. Those usages reflect how the xkms-client
application might consume the key. All other things are out
of scope and disallowed. There've been a few threads on this
in the past, but basically, we just don't want any nonsense
like an n-r bit.

In the particular example you give, there's an additional
reason: we have no explicit concept of a "CA" in xkms,
(nor of a PGP key server), since we want to be independent of
the existence or otherwise of a PKI behind the responder.

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.

> Then I have a few things in the spec I don't understand - perhaps
> errors/mistypings?
> 
> Para 218 ends with: 
> "The <UnverifiedKeyBinding> elements returned are specified by the
> Respond element in the request."
> Shouldn't it say "by the RespondWith element in the request"? The
> schema has no such element as <Respond> anyways.

Sounds right. Might have to wait a while to fix this since the
spec's currently transitioning in the w3c process, and it'd
probably be a bad idea to make any change at all right now.

(Shivaram, Jose: what's the current typo-fixing process given
our current state? Just make a list?)

Regards,
Stephen.

> 
> I hope you can help me clear up these questions.
> 
> Thanks for your attention.
> ---
> Cheers,
> Kenneth
> 
>

Received on Wednesday, 18 May 2005 10:18:57 UTC