As you know from being JOSE chair, Jim, there are numerous use cases for "alg":"none", and its inclusion in JOSE had widespread support. Several people tried to kill it during standardization and the working group stood up for retaining it each time. I can dig up the issuer tracker references if there is any doubt about this.
The last paragraph of JWS Section 5.2 Message Signature or MAC Validation https://tools.ietf.org/html/rfc7515#section-5.2 says: Finally, note that it is an application decision which algorithms may be used in a given context. Even if a JWS can be successfully validated, unless the algorithm(s) used in the JWS are acceptable to the application, it SHOULD consider the JWS to be invalid. This isn't there just because of "none". It's a general statement that applications need to ensure that acceptable algorithms are used. Rejecting obsolete algorithms and/or algorithms not used by the application is just as important as rejecting "none" when used in an inappropriate context. One could even argue that having "none" make it obvious to application writers that the algorithm MUST be checked, thereby increasing security. Note that this point is also covered in the JWT BCP at https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-01#section-3.2. -- Mike -----Original Message----- From: jose <[email protected]> On Behalf Of Jim Schaad Sent: Monday, April 23, 2018 10:22 AM To: 'Neil Madden' <[email protected]>; 'David Adrian' <[email protected]> Cc: 'Mike Jones' <[email protected]>; [email protected] Subject: Re: [jose] [Cfrg] RFC Draft: PASETO - Platform-Agnotic SEcurity TOkens It would make sense for JOSE to add the same tests that are in COSE where the key type is required to be checked before the key value is used. However, if one is only checking for trust based on the public key value, then one has more of a problem than this. One should also be checking that the key type and exponent are also correct. I would be more than happy to shepherd through a draft which deprecates the signature value of none if somebody wants to write it. > -----Original Message----- > From: jose <[email protected]> On Behalf Of Neil Madden > Sent: Monday, April 23, 2018 9:43 AM > To: David Adrian <[email protected]> > Cc: Carsten Bormann <[email protected]>; [email protected]; Mike Jones > <[email protected]>; [email protected] > Subject: Re: [jose] [Cfrg] RFC Draft: PASETO - Platform-Agnotic > SEcurity TOkens > > > > On 23 Apr 2018, at 14:44, David Adrian <[email protected]> wrote: > > > > > If we have to invent a new standard each time an existing standard > > > is > implemented with a security flaw, we have a lot of work to do. > > > > You fundamentally cannot fix a standard with unusable to the point > > of > broken negotiation by extending the negotiation. If you don't want > PASETO to be a new standard, call it JOSEv3. > > I don’t believe that PASETO is actually fundamentally different from > JOSE in this respect. Is there a meaningful distinction between > v1.local.<token> and {“alg”:”v1.local”}.<token> ? > > One of the critical vulnerabilities historically in JOSE > implementations was [1], whereby if an implementation was using RSA > signed JWTs an attacker could get the server’s public key and use it > as if it was a HMAC key to produce a forged JWT with {“alg”:”HS256”} > in the header. If the JWT library just provided a verify(String jwt, > Key key) function then it might be tricked into using the attacker’s > choice of algorithm (HS256) with the server’s RSA public key and the JWT > would validate. Oops! > > This flaw has been rightly criticised, including by the authors of > PASETO. Don’t let the attacker chose the algorithm! > > But wait, aren’t PASETO implementations potentially vulnerable to > *exactly the same vulnerability*?! If my server is set up to use > v2.public (Ed25519) signed PASETO tokens, what is to stop an attacker > grabbing my Ed25519 public key (which is a 32 byte value) and using it > to create a PASETO token using v2.local? Recall that v2.local takes a > 32 byte symmetric key. If the PASETO library just has a function > verify(String paseto, Key key) and looks at the header to decide how > to process the token, then it will have exactly the same vulnerability > that those JOSE libraries had. So how does PASETO the spec make this > vulnerability less likely? > > Looking at the reference implementation [2], it seems that if the > library user didn’t set an allowed purpose then the only thing > stopping this is a type check on the public key class. In other words, > the implementor took extra safe-guards beyond those documented in the > specification. Phew! > > Am I missing something here? As far as I can tell, the PASETO docs and > draft RFC don’t even mention this as a consideration. How is this better than > JOSE? > > [1] https://auth0.com/blog/critical-vulnerabilities-in-json-web-token- > libraries/ > [2] > https://github.com/paragonie/paseto/blob/master/src/Parser.php#L159 > > Neil > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
