ietf
[Top] [All Lists]

RE: [jose] Secdir review of draft-ietf-jose-json-web-signature-31

2014-09-22 20:30:21
My current editor’s draft contains the following security considerations 
subsection, which is derived from Richard’s proposed text.  I’m sending it now 
for working group review, with the intent to publish updated drafts addressing 
all the Gen-ART and secdir comments received, possibly as early as sometime 
tomorrow.

This subsection is over three times the size of any of the other security 
considerations subsections.  It’s my hope, as an editor, that people will 
suggest ways to drastically shorten it, while retaining understandable and 
actionable content, before I publish an updated draft.

I obviously hope that people will also review it for correctness.

                                                                Thank you,
                                                                -- Mike

10.7.  Algorithm Protection

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 
it has not. These attacks have been discussed in detail in the context of CMS 
[RFC6211]. The risk arises when all of the following are true:
·         Verifiers of a signature support multiple algorithms.
·         Given an existing signature, an attacker can find another payload 
that produces the same signature value with a different algorithm.
·         The payload crafted by the attacker is valid in the application 
context.

For example, suppose a verifier is willing to accept both PS256 and PS384 as 
alg values, and a signer creates a signature using PS256. If the attacker can 
craft a payload that has the same SHA-256 digest as the SHA-384 digest of the 
legitimate payload, then the PS256 signature over the bogus payload will be the 
same as the PS384 signature over the legitimate payload.

There are several ways for an application to mitigate algorithm substitution 
attacks:
·         Don't accept signatures using algorithms vulnerable to substitution 
attacks. Algorithm substitution attacks are not possible for all signature 
algorithms. The only algorithms defined in JWA [JWA] that may be vulnerable to 
algorithm substitution attacks are the RSASSA-PSS (PS256, PS384, etc.) 
algorithms. An implementation that does not support RSASSA-PSS or other 
vulnerable algorithms is not susceptible to algorithm substitution attacks. 
Substitution attacks are only feasible if an attacker can compute pre-images 
for a hash function accepted by the recipient. All JWA-defined algorithms use 
SHA-2 hashes, for which there are no known pre-image attacks, as of the time of 
this writing. Until there are attacks against SHA-2 hashes, even 
implementations that support RSASSA-PSS are not susceptible to substitution 
attacks.
·         Require that the alg Header Parameter be carried in the protected 
header. (This is always the case when using the JWS Compact Serialization and 
is the approach taken by CMS [RFC6211].)
·         Include a field containing the algorithm in the application payload, 
and require that it be matched with the alg Header Parameter during 
verification. (This is the approach taken by PKIX [RFC5280].)

<Prev in Thread] Current Thread [Next in Thread>