Re: [jose] [Cfrg] RFC Draft: PASETO - Platform-Agnotic SEcurity TOkens

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 <Michael.Jones@microsoft.com>
> Sent: Monday, April 23, 2018 10:53 AM
> To: Jim Schaad <ietf@augustcellars.com>; 'Neil Madden'
> <neil.e.madden@gmail.com>; 'David Adrian' <davadria@umich.edu>
> Cc: jose@ietf.org
> 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 <jose-bounces@ietf.org> On Behalf Of Jim Schaad
> Sent: Monday, April 23, 2018 10:22 AM
> To: 'Neil Madden' <neil.e.madden@gmail.com>; 'David Adrian'
> <davadria@umich.edu>
> Cc: 'Mike Jones' <Michael.Jones=40microsoft.com@dmarc.ietf.org>;
> jose@ietf.org
> 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 <jose-bounces@ietf.org> On Behalf Of Neil Madden
> > Sent: Monday, April 23, 2018 9:43 AM
> > To: David Adrian <davadria@umich.edu>
> > Cc: Carsten Bormann <cabo@tzi.org>; cfrg@ietf.org; Mike Jones
> > <Michael.Jones=40microsoft.com@dmarc.ietf.org>; jose@ietf.org
> > Subject: Re: [jose] [Cfrg] RFC Draft: PASETO - Platform-Agnotic
> > SEcurity TOkens
> >
> >
> > > On 23 Apr 2018, at 14:44, David Adrian <davadria@umich.edu> 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
> > jose@ietf.org
> > https://www.ietf.org/mailman/listinfo/jose
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose