[tlr@w3.org: XKMS comments]

On behalf of Thomas,


Forwarded message 1

  • From: Thomas Roessler <tlr@w3.org>
  • Date: Mon, 17 Jan 2005 15:58:55 +0100
  • Subject: XKMS comments
  • To: jose.kahan@w3.org
  • Cc: w3t-archive@w3.org
  • Message-ID: <20050117145855.GJ4486@raktajino.does-not-exist.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

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

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

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

Thomas Roessler, W3C   <tlr@w3.org>

Received on Monday, 17 January 2005 15:55:16 UTC