Re: [tlr@w3.org: XKMS comments]

Look likes a good set of fair comments.

Other than the resolutions suggested, (which look fine at first
glance), ought we put in place a better (though non-interoperable!)
fix for the "able to determine whether two revocation codes are
identical" threat which looks, now that he says it, a bit sloppy?

Fixes could be:

- use a salt, chosen at registration time and available
   for querying (needs a new operation, so yuk) at revocation
   time
- use some keybits, which is fine so long as you haven't
   lost the key (key loss being quite likely in a revocation
   scenario)
- lodge foo=H(H(pwd),X) where X is a random integer between 0
   and 15, and at revocation time send all 16 possibles, resulting
   in an 1-in-4 chance of a foo-collision given the same pwd?
   (terrible hack and I've probably gotten the math wrong as usual,
   plus, the 1st revocation exposes the collision in any case, but
   at least the collision isn't apparent from the responder DB)

All sound like a bit too much work at this stage, so would anyone
like to do any of these, or is there a better idea?

Stephen.

Jose Kahan wrote:

> On behalf of Thomas,
> 
> -jose
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> XKMS comments
> From:
> Thomas Roessler <tlr@w3.org>
> Date:
> Mon, 17 Jan 2005 15:58:55 +0100
> To:
> jose.kahan@w3.org
> 
> To:
> jose.kahan@w3.org
> CC:
> w3t-archive@w3.org
> 
> 
> Hi Jos�,
> 
> as discussed last week, here are my comments on the current XKMS
> spec. Please feel free to forward this to the XKMS WG.
> 
> Let me begin with some editorial nits:
> 
> * The spec sometimes mentions AbstractRequestType, and sometimes
>   mentions RequestAbstractType (but obviously means the same type).
>   These should be unified.
>   
> * In paragraphs 188 and 189, the semantics of the ValidityInterval
>   element when used inside a UnverifiedKeyBinding element could be
>   clearer. Currently, the spec says that an UnverifiedKeyBinding
>   "describes" a key binding, but "makes no assertion regarding the
>   status of the key binding."
>   
>   So, what does "the time interval in which the key binding
>   relationship is asserted" mean in a context where no assertion is
>   made?
> 
> 
> Concerning the pass phrase canonicalization steps, I don't have any
> particular concerns, as long as implementations make sure that there
> is enough entropy in the material that's used.
> 
> 
> I have some more substantive concerns with the key revocation
> protocol.
> 
> This protocol basically consists in sending a double hash (the
> RevocationCodeIdentifier) of a (presumably) user-typable or even
> user-picked pass phrase as part of the PrototypeKeyBinding element
> of a RegistrationRequest, and later sending a simple hash of the
> pass phrase (the RevocationCode) to authenticate a
> RevocationRequest.  The spec does not contain any confidentiality
> requirements for these messages, and does not suggest encrypting
> them; paragraph 288 specifically talks about sending the
> RevocationCode "as plaintext."
> 
> An attacker with access to a RevocationCodeIdentifier can launch an
> offline dictionary attack to recover either the RevocationCode or
> the pass phrase.  The intended recipient of these identifiers can
> also, of course, launch an offline dictionary attack.  These
> dictionary attacks are an issue when the underlying pass phrases
> contain too little entropy.
> 
> Further, eavesdroppers with access to RevocationCodeIdentifier
> elements are able to determine whether two revocation codes are
> identical.  If multiple key bindings are associated with the same
> revocation code identifier (and, hence, the same revocation code),
> and an eavesdropper observes one revocation transactions, then this
> eavesdropper is able to create valid revocation requests for any of
> the other key bindings with identical revocation code.
> 
> Based on these observations, I would recommend the following changes
> to the specification text:
> 
> * paragraph 288: "The double MAC calculation ensures that the
>   <RevocationCode> value may be sent as plaintext without the risk
>   of disclosing a value which might have been used by the end-user
>   as a password in another context."
>   
>   I would suggest to strike this text, for several reasons:
>   
>   - As far as low-entropy passwords are concerned, the double MAC
>     calculation doesn't ensure anything: These passwords are made
>     accessible to an offline dictionary attack and can subsequently
>     be compromised.  (They aren't technically disclosed, though.)
>     
>   - The text seems to indirectly encourage re-use of shared secrets
>     across different contexts.  It shouldn't.
>     
>   - The text seems to suggest the use of low-entropy passwords to
>     generate the revocation code.  It shouldn't.
> 
> * Paragraph 363 suggests that "the shared secret SHOULD contain a
>   minimum of 32 bits of entropy if the service implements measures
>   to prevent guessing of the shared secret, and a minimum of 128
>   bits of entropy otherwise."
>   
>   It should, at the very least, be made crystal clear that "measures
>   to prevent guessing of the shared secret" should include strong
>   confidentiality protections for revocation code identifiers and
>   revocation codes, to provide safeguards against the dictionary
>   attacks outlined above, and to protect against attackers
>   recognizing deliberate or accidental collisions of revocation
>   codes.
> 
> * The security considerations part of the document should make clear
>   that implementations should not re-use revocation codes across
>   different key bindings (regardless of the amount of entropy used
>   when generating them).
>   
>   Note that strong confidentiality protection of
>   RevocationCodeIdentifier and RevocationCode elements would also
>   help against this problem.
> 
> 
> Regards,

Received on Monday, 17 January 2005 16:13:16 UTC