On behalf of Thomas,
-jose
Forwarded message 1
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,
--
Thomas Roessler, W3C <tlr@w3.org>