A public test suite along the lines of Project Wycheproof [1] for known vulnerabilities would be extremely valuable in my opinion.
[1] https://github.com/google/wycheproof Neil > On Monday, Apr 23, 2018 at 6:43 pm, Mike Jones <[email protected] > (mailto:[email protected])> wrote: > I realize that, as described in > https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/, > some libraries did allow a RSA public key value to be used as an HMAC key. As > I see it, this is a problem with those implementations - not with the > specification. RSA public keys don't even have the same syntax as HMAC keys! > (The former has "e" and "n" values and "kty":"RSA" and the latter has a "k" > value and "kty":"oct".) An implementation that would allow the two to be used > interchangeably isn't even providing type safety - let alone security. Note > that this implementation problem is already also covered in > https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-01#section-3.1. > > The fact that there have been implementation bugs isn't overly surprising. > That happens in all code. This, to me, makes the case that we should have > good public test suites for JWS/JWE/JWT implementations to ferret out these > bugs - just like we have the OpenID Certification test suite > http://openid.net/certification/ for OpenID Connect implementations. Whereas > changing to a different standard would just result in different bugs, and > would reduce interoperability. > > -- Mike > > -----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
signature.asc
Description: PGP signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
