IETF Logo Mail Archive

Re: [OAUTH-WG] JWT/JWS/JWE confusing base64url decode language

Mike Jones <Michael.Jones@microsoft.com> Sun, 29 March 2015 05:22 UTC

Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECE91A914E for <oauth@ietfa.amsl.com>; Sat, 28 Mar 2015 22:22:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 iKrEZzK4SyrG for <oauth@ietfa.amsl.com>; Sat, 28 Mar 2015 22:22:22 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0784.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:784]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68E4F1A9149 for <oauth@ietf.org>; Sat, 28 Mar 2015 22:22:22 -0700 (PDT)
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.125.14; Sun, 29 Mar 2015 05:22:05 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0125.002; Sun, 29 Mar 2015 05:22:04 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: André DeMarre <andredemarre@gmail.com>, OAuth WG <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] JWT/JWS/JWE confusing base64url decode language
Thread-Index: AQHQadlqUVPskxCKAECiK9qKdhiY3Z0y7OG1
Date: Sun, 29 Mar 2015 05:22:03 +0000
Message-ID: <BY2PR03MB4423A24370CC3A71E01FD0CF5F60@BY2PR03MB442.namprd03.prod.outlook.com>
References: <CAEwGkqAzK_KwAHXDtyDAr2D8gdNxwV-pjb+f7D6pFhF4Apkf5A@mail.gmail.com>
In-Reply-To: <CAEwGkqAzK_KwAHXDtyDAr2D8gdNxwV-pjb+f7D6pFhF4Apkf5A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [166.170.43.196]
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(377454003)(46102003)(16236675004)(40100003)(2950100001)(2900100001)(66066001)(19580405001)(19580395003)(92566002)(19617315012)(102836002)(76576001)(77096005)(15975445007)(19625215002)(33656002)(74316001)(87936001)(575784001)(122556002)(86612001)(62966003)(77156002)(107886001)(54356999)(2656002)(86362001)(50986999)(99286002)(76176999)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
x-microsoft-antispam-prvs: <BY2PR03MB4414441E810DBD068F29B63F5F60@BY2PR03MB441.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441;
x-forefront-prvs: 0530FCB552
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4423A24370CC3A71E01FD0CF5F60BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2015 05:22:03.6297 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/Mq453cOdxIaW13zonbHiVSyBNJ4>
Subject: Re: [OAUTH-WG] JWT/JWS/JWE confusing base64url decode language
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Mar 2015 05:22:24 -0000

(A)
________________________________
From: André DeMarre<mailto:andredemarre@gmail.com>
Sent: ‎3/‎28/‎2015 9:32 PM
To: OAuth WG<mailto:oauth@ietf.org>
Subject: [OAUTH-WG] JWT/JWS/JWE confusing base64url decode language

I find the following sentence confusing:

https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32#section-7.2
        Base64url decode the Encoded JOSE Header following the
        restriction that no line breaks, white space, or other
        additional characters have been used.

When it says to decode following the restriction that certain
characters have not been used, is this supposed to mean (A) that those
characters are illegal in the encoded representation, or (B) that
those characters must be discarded if encountered in the decode
function?

Disregarding domain knowledge and examining the prose alone, I would
warily conclude A.

The difference is significant, affecting the strictness of token
validation. Consider a JWT with an arbitrary 0x0A line break somewhere
before the first period, resulting in the following JOSE header with a
line break:

eyJ0eXAiOiJKV1Qi
LA0KICJhbGciOiJIUzI1NiJ9

Similarly, the following header could result from a base64url encoder
that retains the common "=" padding:
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldUIn0=

Under interpretation A, the headers are invalid and cannot be decoded.
Under interpretation B, the line break and "=" would be ignored, and
the headers would be decoded successfully.

How strict do we want JWT/JWS/JWE validation to be?

Whichever the case, I think the paragraph quoted above should simply
omit the 'restriction' comment:
        Base64url decode the Encoded JOSE Header.

The original phrasing apparently comes from the JWS spec, and is
duplicated for JWE:
https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-5.2
https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-40#section-5.2

If needed, further instruction on how to handle unexpected characters
should be done normatively in the base64url definition
(https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-2)
or maybe in the JWT structure overview.

Notice also that the example C# base64urldecode() function
(https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#appendix-C)
is lenient. So lenient in fact that it accepts BOTH the regular base64
and base64url encodings from RFC 4648.


Regards,
Andre DeMarre

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

v2.23.0 | Report a Bug | By Email