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

Jim Schaad <ietf@augustcellars.com> Sat, 28 April 2018 18:19 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C617412E86A for <jose@ietfa.amsl.com>; Sat, 28 Apr 2018 11:19:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgBY5i0hF5xy for <jose@ietfa.amsl.com>; Sat, 28 Apr 2018 11:18:59 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 682D51276AF for <jose@ietf.org>; Sat, 28 Apr 2018 11:18:58 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 28 Apr 2018 11:16:04 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Mike Jones' <Michael.Jones@microsoft.com>
CC: <jose@ietf.org>
References: <CAKws9z15m6WY+-mz5D01vxB4s-TE7nQN56=ssYt=vz3z4gAj6A@mail.gmail.com> <DBC2F048-C949-4362-8FD0-A43A54767B03@gmail.com> <CAKws9z277JLfv7Pb9wSkJ7zYR8FzoAfiXuFS6Vq0x32-3bWx7Q@mail.gmail.com> <DB58CEFE-ED93-4C1C-9212-B622DFCCFFB9@gmail.com> <A6784DBB-C147-40B7-8A5C-E96F431020F6@tzi.org> <SN6PR00MB0301F595CF57BF58D4BAA4D2F5B40@SN6PR00MB0301.namprd00.prod.outlook.com> <CACf5n78R3Fur_eunfiQnM9+enbV5vrXs8aW1sfmU6HhV6_3WVA@mail.gmail.com> <9F9C6A42-0E89-4AB9-915C-8B208D9C31FD@gmail.com> <011201d3db27$a6275780$f2760680$@augustcellars.com> <DM5PR00MB0296B43261FCA453360BF1BAF5890@DM5PR00MB0296.namprd00.prod.outlook.com>
In-Reply-To: <DM5PR00MB0296B43261FCA453360BF1BAF5890@DM5PR00MB0296.namprd00.prod.outlook.com>
Date: Sat, 28 Apr 2018 11:18:29 -0700
Message-ID: <038a01d3df1d$50e273a0$f2a75ae0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHlGBUPGXUrORj8prpGhSDjlEvIQQK77z3DAvDhKnwB/72BLgHke8WvAKpcxpYA/xS+4gIVHdYQAwcThAAB6Fn5zaNiAcnA
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/B-muvFmVaDeoBpQpa0MuRFitLQM>
Subject: Re: [jose] [Cfrg] RFC Draft: PASETO - Platform-Agnotic SEcurity TOkens
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Apr 2018 18:19:02 -0000

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>om>; 'Neil Madden'
> <neil.e.madden@gmail.com>om>; '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>om>; 'David Adrian'
> <davadria@umich.edu>
> Cc: 'Mike Jones' <Michael.Jones=40microsoft.com@dmarc.ietf.org>rg>;
> 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>rg>; cfrg@ietf.org; Mike Jones
> > <Michael.Jones=40microsoft.com@dmarc.ietf.org>rg>; 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