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
pgpXHvRpckwE9.pgp
Description: OpenPGP digital signature
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
