> Implementations that support plaintext JWS objects (i.e., the "alg" value > "none") MUST NOT accept such objects as valid unless… > For example, the "verify" method of a hypothetical JWS software library…
“unprotected JOSE message” would be better than “plaintext JWS object”. “plaintext” usually means the input to encryption; the major point is not to treat "alg": "none" like signed or MACed messages so don’t call it a JWS, even if it has the same syntax; “object” often means a set of name/value pairs. I’m not sure a verify() method means the same to everyone. In Richard’s PyJOSE library I think verify() both parses and applies any necessary crypto checks. In the Nimbus-JOSE library, in contrast, parse() is quite separate from verify(). A verify() method doesn’t exist when parse() sees an "alg": "none" message. Consequently I don’t think talking about verify() is clear enough. If an app is expecting a MACed message, it is crucial it doesn’t inadvertently accept an "alg": "none" message. It is also crucial that it doesn’t inadvertently accept an "alg": "RS256" message. While only the 1 person you shared a symmetric key with can create MACed message that passes verify(), anyone certified by any commonly trusted CA can create a signed message that passes verify(). Suggested text: JOSE messages can involve a variety of cryptographic operations (or even no cryptography) providing a range of very different security properties. It is crucial that, on receiving a JOSE message, an application confirms that this specific message has the required security properties. To reduce the risk that applications inadvertently accept inadequately protected JOSE messages, JOSE library APIs ought to expose the security properties of a message in ways that applications cannot ignore. For example, a strongly typed language can use a distinct class for unprotected messages that is not a sub-class of the class used for MACed messages. As another example, distinct methods can be provided for verifying the authenticity of a JOSE message with a shared symmetric key (eg verifyMAC(secret)), and verifying an asymmetric signature against trusted root CAs (eg verifyPKI(roots)). [The best way for JOSE specs to encourage safe API designs is to re-structure the text so a JOSE message with different security properties is not specified in a sub-section of another sort of message.] -- James Manger From: [email protected] [mailto:[email protected]] On Behalf Of Mike Jones Sent: Friday, 6 September 2013 5:22 AM To: Matt Miller (mamille2) Cc: [email protected] Subject: Re: [jose] Text about applications and "alg":"none" Thanks Matt, for suggesting the text. The version below has slight edits to make it editorially consistent with the terminology used elsewhere in the specs and to give the acceptable algorithm list approach equal billing with the Boolean approach. Implementations that support plaintext JWS objects (i.e., the "alg" value "none") MUST NOT accept such objects as valid unless the application specifies that it is acceptable for a specific object to be non-integrity-protected. Implementations MUST NOT accept plaintext JWS objects by default. For example, the "verify" method of a hypothetical JWS software library might have a boolean "acceptUnsigned" parameter (which defaults to "false") that indicates "none" is an acceptable "alg" value. As another example, the “verify” method might take a list of algorithms that are acceptable to the application as a parameter and would reject plaintext JWS values if “none” is not in that list. In order to mitigate downgrade attacks, applications MUST NOT signal acceptance of plaintext JWS objects at a global level, and SHOULD signal acceptance on a per-object basis. For example, suppose an application accepts JWS objects over two channels, (1) HTTP and (2) HTTPS with client authentication. It requires a JWS signature on objects received over HTTP, but accepts plaintext JWS objects over HTTPS. If the application were to globally indicate that "none" is acceptable, then an attacker could provide it with an unsigned object over HTTP and still have that object successfully validate. Instead, the application needs indicate acceptance of "none" for each object received over HTTPS (e.g., by setting "acceptUnsigned" to "true" for the first hypothetical JWS software library above), but not for each object received over HTTP. -- Mike From: Richard Barnes [mailto:[email protected]] Sent: Thursday, September 05, 2013 9:02 AM To: Matt Miller (mamille2) Cc: Mike Jones; [email protected]<mailto:[email protected]> Subject: Re: [jose] Text about applications and "alg":"none" That text is fine with me. I would prefer the SHOULD be a MUST, but I could imagine some interface like RealJWSVerifier that takes things from HTTP, vs. NotReallyAJWSVerifierDangerWillRobinson from HTTPS. Though it does highlight the crazy contortions we're having to go through to get "none" right, rather than just defining a separate syntax. On Thu, Sep 5, 2013 at 11:55 AM, Matt Miller (mamille2) <[email protected]<mailto:[email protected]>> wrote: I agree with the intent, but I'm not very comfortable with the actual text. It reads too much like software interface design, and I'd rather avoid telling people exactly how to write their software. My suggested change (still makes me squeamish, but I can live with it): """ Implementations that support unsigned JWS objects (i.e., the "alg" value "none") MUST NOT accept such objects as valid unless the application specifies that it is acceptable for a specific object to be unsigned. Implementations MUST NOT accept unsigned JWS objects by default. For example, the "verify" method of a hypothetical JWS software library might have a boolean "acceptUnsigned" parameter (which defaults to "false") that indicates "none" is an acceptable "alg" value. In order to mitigate downgrade attacks, applications MUST NOT indicate acceptance of unsigned JWS objects at a global level, and SHOULD specify acceptance on a per-object basis. For example, suppose an application accepts JWS objects over two channels, (1) HTTP and (2) HTTPS with client authentication. It requires a JWS signature on objects received over HTTP, but accepts unsigned JWS objects over HTTPS. If the application globally indicates that "none" is acceptable, then an attacker could provide it with an unsigned object over HTTP and still have that object considered valid. Instead, the application needs indicate acceptance of "none" for each object received over HTTPS (e.g., by setting "acceptUnsigned" to "true" for the hypothetical JWS software library above), but not for each object received over HTTP. """ - m&m Matt Miller < [email protected]<mailto:[email protected]> > Cisco Systems, Inc. On Sep 5, 2013, at 9:10 AM, Richard Barnes <[email protected]<mailto:[email protected]>> wrote: > Thinking on this a little more, it seems like it would be simpler to state > this just as an "allow unsigned" flag, rather than a more general > "acceptable algorithms" set. That way we don't have to worry about all the > downgrade scenarios when you have "none" along with something else. > > """ > Implementations that support unsigned JWS objects (i.e., the "alg" value > "none") MUST NOT accept such objects as valid unless the application > specifies that it is acceptable for a specific object to be unsigned. For > example, the "verify" method of a JWS library might have a boolean > "acceptUnsigned" parameter that would indicate that "none" is an acceptable > "alg" value. > > Applications MUST specify this flag on a per-object basis, since otherwise > they will be vulnerable to downgrade attacks. For example, suppose an > application accepts JWS objects over two channels, (1) HTTP and (2) HTTPS > with client authentication. It requires a JWS signature on objects received > over HTTP, but accepts unsigned JWS objects over HTTPS. If the application > sets a global setting that "none" is acceptable, then an attacker could > provide it with an unsigned object over HTTP and still have that object > considered valid. Instead, the application needs to set the > "acceptUnsigned" flag to "false" for each object received over HTTP, and to > "true" for each object received over HTTPS. > """ > > This makes the equivalence between the "separate object" and "constrained > verify" cases a lot clearer. On the one hand, you would have > "jose.somethingNotVerify(JWP)", and on the other hand, you would have > "jose.verify(JWP, acceptUnsigned=True)". > > --Richard > > > > > On Tue, Sep 3, 2013 at 2:02 PM, Mike Jones > <[email protected]<mailto:[email protected]>>wrote: > >> I took an action item during the last call to write text along the lines >> suggested by ekr about applications and "alg":"none". I propose that the >> following text be included:**** >> >> ** ** >> >> It is RECOMMENDED that libraries provide applications a means of >> specifying the list of acceptable algorithms used in a JWS object in a way >> that causes inputs using algorithms outside the specified set to be >> rejected. In particular, it is intended for applications to use this >> mechanism to exclude accepting inputs using "alg":"none" in security >> contexts where non-integrity protected inputs are not acceptable.**** >> >> ** ** >> >> Feedback/proposed wording refinements welcomed.**** >> >> ** ** >> >> -- Mike*** >> *
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
