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

To close 330 tlr 2

In an Unverified Key Binding, the validity interval should not be
interpreted as 
"the time interval in which the key binding relationship is asserted"
but rather as
"the time interval for which the key binding relationship is requested
to be asserted"

This is an editorial change around paragraphs 188 and 189.

Stephen.

El lun, 17-01-2005 a las 15:54, Jose Kahan escribió:

> On behalf of Thomas,
> 
> -jose
> 
> 
> ______________________________________________________________________
> 
> From: Thomas Roessler <tlr@w3.org>
> To: jose.kahan@w3.org
> Cc: w3t-archive@w3.org
> Subject: XKMS comments
> Date: Mon, 17 Jan 2005 15:58:55 +0100
> 
> 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,