Re: [Gen-art] Gen-ART Last Call review of draft-baeuerle-netnews-cancel-lock-05

[Michael Bäuerle <[e-mail]>]

Paul Kyzivat wrote:
> 
> [...]
> General Comments:
> 
> I have not attempted to validate the security properties of this 
> document - leaving that to a security review.
> 
> I have also not attempted to verify the operational suitability of this 
> mechanism because I don't have the experience needed to do so.
> 
> Issues:
> 
> Major: 1
> Minor: 3
> Nits:  0
> 
> (1) MAJOR:
> 
> [Problem with ABNF syntax of header fields]

Hi Paul,

Julien Élie has proposed a new syntax definition.

> (2) Minor:
> 
> In Section 3.5, step 1 says to hash the key using the algorithm from its 
> scheme. But IIUC the scheme describes the algorithm that has already 
> been used when constructing the Cancel-Key header.

No. There are two different operations that use a hash function.

The recommended algorithm described in Section 4 calculates:
| 
| K = HMAC(uid+mid, sec)

K is then used for <c-key-string> in the Cancel-Key header field only
with Base64 as transfer encoding (no further hash operation is used):

   c-key-string = Base64(K)

HMAC can be based on a different hash function than the one in <scheme>
(because a serving agent doesn't need to know how K was calculated for
the check algorithm defined in Section 3.5).

A value of e.g. "sha256" for <scheme> in a Cancel-Key header field
doesn't mean that SHA256 was used to generate this field, but that the
corresponding Cancel-Lock header field (in the original article) contains
the value of <c-key-string> hashed with SHA256 (and finally Base64
encoded).

The hash function defined by <scheme> is used to generate <c-lock-string>
elements for the Cancel-Lock header field:

   c-lock-string = Base64(hash(c-key-string))
                          ^^^^
This hash function is the one specified with <scheme> (in both matching
elements <c-lock> and <c-key> in the Cancel-Lock and Cancel-Key header
fields of the two articles involved).

> IIUC the serving 
> agent need not hash the provided key. Rather it only uses the scheme to 
> select the locks to compare the hash against.

<scheme> is used for both purposes.

Step 1 is defined in Section 3.5 as:
| 
| 1. The <c-key-string> part of the <c-key> element is hashed using
|    the algorithm defined by its <scheme> part.

This is the operation for <c-lock-string> listed above.
The hash operation is required here because if the elements from the
Cancel-Key header field would be directly comparable, everybody could
forge them (copy from the public original article).
The hijack/abuse attack against <c-key-string> elements on their way
through the network (as discussed for the review from David Mandelberg)
is not the same. The relevant difference is who can *create* valid
<c-key-string> elements.

In Step 2 <scheme> is used again to skip <c-lock-string> elements that
were created using different hash functions. The compare operation from
Step 2 (with first operand from Step 1) is:

   Base64(hash(c-key-string)) == c-lock-string

The Base64 encode part is not explicitly noted in Step 1.
Base64 decoding the second operand instead would work too:

   hash(c-key-string) == Base64_decode(c-lock-string)

To be unambiguous and consistent with the definition of <c-lock-string>
from Section 2.1, the words for Step 1 in Section 3.5 maybe should
explicitly cover the Base64 encode operation. Suggestion:

   1. The <c-key-string> part of the <c-key> element is hashed using
      the algorithm defined by its <scheme> part and then Base64
      encoded.

> (3) Minor:
> [...]

Issue 2 should be discussed first.

The hash function used for HMAC in Section 4 is unrelated to <scheme>
and unrelated to the check algorithm from Section 3.5.

On the other hand, the hash function from <scheme> is not used to
create <c-key-string> elements for the Cancel-Key header field.


-- 
Michael Bäuerle