Hi Neil,
thanks for your feedback! The security considerations are certainly far
from complete in this first draft (and didn't intend to be). Your
comments will help us to improve this part of the draft.
Am 23.06.22 um 20:52 schrieb Neil Madden:
I’m not entirely sure the OAuth WG is a suitable venue for this kind
of document. It should at least get some review from CFRG, to get
feedback on the crypto aspects.
That would certainly be appropriate!
I have some initial comments about the cryptography being used.
Commitments to claim values are of the form HASH(SALT | CLAIM-VALUE),
but this does not necessarily commit the sender to CLAIM-VALUE. In
section 7.4, I think you need to say that HASH must be collision
resistant - otherwise the user can find two (salt, claim-value) pairs
that collide and get the issuer to sign one and then reveal the other
pair to the downstream party.
+1
The fact that HASH(SALT | CLAIM-VALUE) is vulnerable to length
extension attacks is also troubling, even if I can’t see an immediate
attack. But it’s a weird property that Bob, for example, could make a
commitment to some extension of one of Alice’s claims without actually
knowing her claim value.
That would mean the Bob would need to be an issuer in this case?
You can address both of these issues by instead using a compactly
committing PRF [1], such as HMAC- i.e., HMAC-HASH(SALT, CLAIM-VALUE)
rather than simple prefix hash.
Given the advantages, we will consider using an HMAC.
It doesn’t seem great to say that you can use any hash algorithm in
the IANA registry, but then to rule out half of them as being not
suitable in the security considerations - this list may go out of date
as other hash algorithms are broken. Is it possible to update the IANA
registry with a Recommended Y/N column? Also, shake128 and shake256
are not collision-resistant hash functions, they are XOFs that can
produce any length of output - e.g. shake128 with a 32-bit output
would not be collision-resistant and thus would not be at all suitable
for this usage. Given these considerations, I might be tempted to
create a new IANA registry, or perhaps just pick one good hash
function. (Or maybe just use the same hash algorithm as the signature?)
I don't know of such a registry, but I'm certain the current limitations
in our spec are not sufficient and we need to improve this.
-Daniel
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
