Mike, I am aware that there are probably still a large number of systems that want to have the none algorithm. I am also aware that there have been a large number of security attacks on JOSE that have been attributed to the use of the none algorithm. Given the perception, I believe that it is time to have a discussion on this issue again. An ID to do this would be the correct trigger.
Jim > -----Original Message----- > From: Mike Jones <[email protected]> > Sent: Monday, April 23, 2018 10:53 AM > To: Jim Schaad <[email protected]>; 'Neil Madden' > <[email protected]>; 'David Adrian' <[email protected]> > Cc: [email protected] > Subject: RE: [jose] [Cfrg] RFC Draft: PASETO - Platform-Agnotic SEcurity > TOkens > > 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
