Also forwarding this to the OAuth WG, given Kathleen's comments on the JWT
security considerations section. (However, please conduct discussions about
the JOSE text on the j...@ietf.org<mailto:j...@ietf.org> list and only reply
here if you are proposing a change to the JWT security considerations section.)
-- Mike
From: Mike Jones
Sent: Monday, June 09, 2014 5:32 PM
To: j...@ietf.org
Cc: Kathleen Moriarty
Subject: Proposed Security Considerations sections changes
In response to Kathleen's requests to beef up the security considerations
sections, I propose the following 9 actions:
1. In the JWE spec, add the heading "11.1. Adaptive Chosen-Ciphertext Attacks"
before the Security Considerations text beginning:
When decrypting, particular care must be taken not to allow the JWE
recipient to be used as an oracle for decrypting messages.
2. At the end of the JWE Security Considerations, add the text:
11.2. Timing Attacks
To mitigate the timing attacks described in RFC
3218<http://tools.ietf.org/html/rfc3218>
[RFC3218<http://tools.ietf.org/html/rfc3218>], the
recipient MUST NOT distinguish between format, padding, and
length errors of encrypted keys. It is strongly recommended, in
the event of receiving an improperly formatted key, that the
receiver substitute a randomly generated CEK and proceed to the
next step, to mitigate timing attacks.
3. Remove the text from step 2 above from the place it occurs earlier (in JWE
Section 5.2, step 10), and instead reference the security considerations text
there.
4. Add JWA Security Considerations subsections on "Adaptive Chosen-Ciphertext
Attacks" and "Timing Attacks", which reference the JWE subsections (rather
duplicating the text in JWA).
5. In the JWK spec, add the heading "8.1. Key Provenance and Trust" before the
security considerations text beginning:
One should place no more trust in the data associated with a key than
in than the method by which it was obtained and in the
trustworthiness of the entity asserting an association with the key.
6. In the JWK spec, add the heading "8.2. Preventing Disclosure of Non-Public
Key Information" before the security considerations text beginning:
Private and symmetric keys MUST be protected from disclosure to
unintended parties.
7. In the JWK spec, replace the current text citing XML DSIG 2.0 with the
following and move it into the Key Provenance and Trust section:
The security considerations in Section 12.3 of XML DSIG 2.0
[W3C.NOTE-xmldsig-core2-20130411<http://tools.ietf.org/html/draft-ietf-jose-json-web-key-26#ref-W3C.NOTE-xmldsig-core2-20130411>],
about the strength of a signature
depending upon all links in the security chain also apply
to this specification.
8. In the JWK spec, add the new security considerations text:
11.2. RSA Private Key Representations and Blinding
The RSA Key blinding operation [Kocher], which is a defense
against some timing attacks, requires all of the
RSA key values "n", "e", and "d". However,
some RSA private key representations do not include the
public exponent "e", but only include the modulus "n"
and the private exponent "d". This is true, for instance,
of the Java RSAPrivateKeySpec API, which does not include
the public exponent "e" as a parameter. So as to enable
RSA key blinding, such representations should be avoided.
For Java, the RSAPrivateCrtKeySpec API can be used instead.
Section 8.2.2(i) of The Handbook of Applied Cryptography
[citation] discusses how to compute the remaining private key
parameters, if needed, using only "n", "e", and "e".
9. In the JWA spec, add a security considerations subsection "RSA Private Key
Representations and Blinding" which references this JWK subsection (rather
duplicating the text in JWA).
Does the working group agree with these changes? Are there other changes that
working group members believe are also needed? (If so, please propose the
desired specific wording.)
Kathleen, do these changes accomplish your goal? If not, can you please
propose specific additional text changes that you'd also like to see?
-- Mike
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
