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

Neil Madden <neil.e.madden@gmail.com> Mon, 23 April 2018 18:13 UTC

Return-Path: <neil.e.madden@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8A612D88B; Mon, 23 Apr 2018 11:13:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 NG4pb6j38zXl; Mon, 23 Apr 2018 11:13:51 -0700 (PDT)
Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51909126C0F; Mon, 23 Apr 2018 11:13:51 -0700 (PDT)
Received: by mail-wr0-x234.google.com with SMTP id s18-v6so43775690wrg.9; Mon, 23 Apr 2018 11:13:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=cI/qbuhbqJedqU0h98BWS8pbb5zDahg+V9vfkDkn1Cg=; b=u+uDWZdtU1n+2Tg2YAgOakYGXAXxdnsmwN6B32Pis3yqOH8Ow5ZkOpaMuwkUP+DMAz 7cTh9zH/akE8lv84sj/3oQWnPKUkzGrVJzHgs1rW9yqwNxrD5Tip1X48Glvev2rk0k0H WbOSCTGFjMQ2UG/r6hJCVDlcFneb9+2vvQ004dlPhzPFeNiuBRTa8K55LIxAefZ2VdBz gOac8pdZtNgx9bk2BhkohK2lchlXGgjL1HnBzeTL3Hw+2OAan29yao/01F90+nY/EEp3 vqesSk+WN496Ou1yF5qSh+WXSPLbywa/cs5CGsN+yLiuMQBbycNB0LRuvt8PNcLmIXBp MFvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=cI/qbuhbqJedqU0h98BWS8pbb5zDahg+V9vfkDkn1Cg=; b=OFS+or/X/z1DP04evg4SmYPg5a1mmbqYIrA0/mo4uECvgfxArqeyLLqHmha3lPEpSN sDAyEqlzma+ni9Hi2QS9RSuze6GpeXxDK08cmIruZ6O+cYsaWmrck1sdqy4Z20XMC1wZ uT8LSxkIT33WNX+XjVsrxLBsMz3Jd1lBdAjgplW5tccs9y4btiapOZLXsGs/YhcIc7zd IF4sNT9yW6scdplfs7kKo/8TpjXGLcqQrcMqBPHhXRiqPTSUDLFOhwl98yW1HXA1Ne9f PVwSskgCI5Ss16iET1LaZGmYtoM1kJ+2ILDhp/R4wT2YnfTqgdfcCTNezRRfIlSwfcim 7rTA==
X-Gm-Message-State: ALQs6tAJ6NgmPW/dfvFEEcBhR118OjNMCCOOegHBFVcl76uwm3UNAblZ UsgXleYeo+jpk5iEQ97xiyI=
X-Google-Smtp-Source: AIpwx48YCmDn2EK+3wpVmnJifcazExvispm+EC49BRaCqZVO5/mdDGbONGEuPB8qdF3Tp4JTH7h9Ng==
X-Received: by 10.28.146.136 with SMTP id u130mr10812798wmd.125.1524507229746; Mon, 23 Apr 2018 11:13:49 -0700 (PDT)
Received: from [192.168.1.81] (72.142.200.146.dyn.plus.net. [146.200.142.72]) by smtp.gmail.com with ESMTPSA id a139sm8122797wma.43.2018.04.23.11.13.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Apr 2018 11:13:48 -0700 (PDT)
Date: Mon, 23 Apr 2018 19:13:45 +0100
From: Neil Madden <neil.e.madden@gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>, David Adrian <davadria@umich.edu>
Cc: "=?utf-8?Q?cfrg=40ietf.org?=" <cfrg@ietf.org>, Carsten Bormann <cabo@tzi.org>, "=?utf-8?Q?jose=40ietf.org?=" <jose@ietf.org>
Message-ID: <b3fe3c35-061d-4858-a4a1-8d6db3bf2d1c@Canary>
In-Reply-To: <DM5PR00MB02962CC566F258FF69460CC7F5890@DM5PR00MB0296.namprd00.prod.outlook.com>
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> <DM5PR00MB02962CC566F258FF69460CC7F5890@DM5PR00MB0296.namprd00.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="5ade225b_327b23c6_ec2"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/PSVwk75yvm-zb16fUUA8AN_HJXw>
Subject: Re: [Cfrg] [jose] RFC Draft: PASETO - Platform-Agnotic SEcurity TOkens
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Apr 2018 18:13:55 -0000

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 <Michael.Jones@microsoft.com (mailto:Michael.Jones@microsoft.com)> 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 <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