|
Thanks Richard. Your proposed text uses the “RS1” and “PS1” algorithms, which WebCrypto has but JOSE doesn’t. Can you revise the examples to make the same
points using only algorithms in JWA? Thanks again, -- Mike From: Richard Barnes [mailto:rlb@xxxxxx]
""" In some usages of JWS, there is a risk of algorithm substitution attacks, in which an attacker can use an existing signature value with a different signature algorithm to make it appear that a signer has signed something that he actually
has not. These attacks have been discussed in detail in the context of CMS {{RFC 6211}}. The risk arises when all of the following are true:
* Given an existing signature, an attacker can find another payload that produces the same signature value with a weaker algorithm * In particular, the payload crafted by the attacker is valid in a given application-layer context For example, suppose a verifier is willing to accept both "PS1" and "PS256" as "alg" values, and a signer creates a signature using "PS256". If the attacker can craft a payload that has the same SHA-1 digest has as the SHA-256 digest of
the legitimate payload, then the "PS1" signature over the bogus payload will be the same as the "PS256" signature over the legitimate payload. There are several ways for an application using JOSE to mitigate algorithm substitution attacks: * Don't accept signatures using vulnerable algorithms: Algorithm substitution attacks do not arise for all signature algorithms.
* The only algorithms defined in JWA {{I-D.ietf-jose-json-web-algorithms}} that is vulnerable to algorithm substitution attacks is RSA-PSS ("PS1", "PS256", etc.). An implementation that does not support RSA-PSS is not vulnerable to algorithm
substitution attacks. * Require that the "alg" parameter be carried in the protected header. (This is the approach taken by RFC 6211.) * Include a field reflecting the algorithm in the application payload, and require that it be matched with the "alg" parameter during verification (This is the approach taken by PKIX {{RFC5280}}.) Of these mitigations, the only sure solution is the first. Signing over the "alg" parameter (directly or indirectly) only makes the attacker's work more difficult, by requiring that the bogus payload also contain bogus information about
the signing algorithm. They do not prevent attack by a sufficiently powerful attacker. """ On Fri, Sep 19, 2014 at 2:49 PM, Mike Jones <Michael.Jones@xxxxxxxxxxxxx> wrote: I would appreciate it if you would write a draft of the proposed security considerations text, Richard.
Perhaps title the section “Unsecured Algorithm Values”. Thanks! -- Mike From: Richard Barnes [mailto:rlb@xxxxxx]
Richard Barnes writes: I'm perfectly happy to have it documented in the Security Considerations. Mike: Should I generate some text, or do you want to take a stab? |