Re: [OAUTH-WG] Correct use of jku claims in JWT/JWS bearer assertions
Mike Jones <Michael.Jones@microsoft.com> Tue, 04 March 2014 16:23 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 700E41A01C5; Tue, 4 Mar 2014 08:23:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 08e8HBMdvrGw; Tue, 4 Mar 2014 08:23:13 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6B61A00F5; Tue, 4 Mar 2014 08:23:12 -0800 (PST)
Received: from BY2PR03CA029.namprd03.prod.outlook.com (10.242.234.150) by BY2PR03MB126.namprd03.prod.outlook.com (10.242.36.21) with Microsoft SMTP Server (TLS) id 15.0.888.9; Tue, 4 Mar 2014 16:23:07 +0000
Received: from BY2FFO11FD049.protection.gbl (2a01:111:f400:7c0c::135) by BY2PR03CA029.outlook.office365.com (2a01:111:e400:2c2c::22) with Microsoft SMTP Server (TLS) id 15.0.888.9 via Frontend Transport; Tue, 4 Mar 2014 16:23:07 +0000
Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD049.mail.protection.outlook.com (10.1.15.186) with Microsoft SMTP Server (TLS) id 15.0.888.9 via Frontend Transport; Tue, 4 Mar 2014 16:23:07 +0000
Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.240]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0174.002; Tue, 4 Mar 2014 16:22:34 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Brian Campbell <bcampbell@pingidentity.com>, Jared Hanson <jaredhanson@gmail.com>, "jose@ietf.org" <jose@ietf.org>
Thread-Topic: [OAUTH-WG] Correct use of jku claims in JWT/JWS bearer assertions
Thread-Index: Ac83xfPOqOa+UrzkRZqei9l+wTZyJQ==
Date: Tue, 04 Mar 2014 16:22:34 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739439A0B00C9@TK5EX14MBXC286.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.35]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439A0B00C9TK5EX14MBXC286r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(438001)(377454003)(199002)(189002)(164054003)(51704005)(24454002)(13464003)(80976001)(50986001)(69226001)(49866001)(81542001)(87266001)(54356001)(76176001)(81342001)(51856001)(33656001)(76482001)(81686001)(74876001)(87936001)(47976001)(95666003)(15202345003)(46102001)(81816001)(2656002)(85806002)(74706001)(54316002)(92566001)(65816001)(19300405004)(80022001)(56816005)(90146001)(92726001)(85306002)(94316002)(66066001)(15188155005)(93136001)(74662001)(47446002)(74502001)(86612001)(77096001)(95416001)(31966008)(15395725003)(16236675002)(86362001)(94946001)(84326002)(512954002)(93516002)(76786001)(76796001)(15975445006)(63696002)(71186001)(53806001)(79102001)(20776003)(55846006)(74366001)(85852003)(4396001)(56776001)(47736001)(6806004)(19580395003)(44976005)(83322001)(77982001)(19580405001)(59766001)(16799955002)(83072002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB126; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:AF47F1FD.A73EB112.2EE3BC4B.4EF6BDCD.20594; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 01401330D1
Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com;
X-OriginatorOrg: microsoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/thqxFwhuBOv_4NttY1HO9OIlXbA
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Correct use of jku claims in JWT/JWS bearer assertions
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: Tue, 04 Mar 2014 16:23:21 -0000
To this, I'll add that the OpenID Connect ID Token specification at http://openid.net/specs/openid-connect-core-1_0.html#IDToken adds this, prohibiting the use of header parameters to communicate the keys: ID Tokens SHOULD NOT use the JWS or JWE x5u, x5c, jku, or jwk header parameter fields. Instead, references to keys used are communicated in advance using Discovery and Registration parameters, per Section 10 (Signatures and Encryption)<http://openid.net/specs/openid-connect-core-1_0.html#SigEnc>. This is for exactly the reasons described in this thread. -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell Sent: Tuesday, March 04, 2014 7:41 AM To: Jared Hanson; jose@ietf.org Cc: oauth Subject: Re: [OAUTH-WG] Correct use of jku claims in JWT/JWS bearer assertions I might be suffering from a touch of confirmation bias but I think this underscores what I was trying to say near the end of the JOSE session in Vancouver during the "key finding algorithm" discussion. Namely that finding a key is not the same as trusting a key and that I'm concerned that explaining how to find a key might lead to implementations that blindly trust whatever key is found. Looking again at the drafts, I found some guidance/precautionary text in JWS and JWT (there might be more I missed), which I've copied with references below. I think that's all there is and I don't know if it's really sufficient. Nor do I know if either WG could agree on saying much more specific. That's probably not exactly what you were looking for, Jared, but was what I could dig up. Maybe some more discussion will be catalyzed. The newish Notes on Key Selection appendix in JWS [0] has this cautionary text: 4. Make trust decisions about the keys. Signatures made with keys not meeting the application's trust criteria would not be accepted. Such criteria might include, but is not limited to the source of the key, whether the TLS certificate validates for keys retrieved from URLs, whether a key in an X.509 certificate is backed by a valid certificate chain, and other information known by the application. And the last paragraph of the Security Considerations in JWT [1], which I think was just recently added in -18, also has some words of caution: "The contents of a JWT cannot be relied upon in a trust decision unless its contents have been cryptographically secured and bound to the context necessary for the trust decision. In particular, the key(s) used to sign and/or encrypt the JWT will typically need to verifiably be under the control of the party identified as the issuer of the JWT." [0] http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-23#appendix-D [1] http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-18#section-11 On Wed, Feb 12, 2014 at 6:26 PM, Jared Hanson <jaredhanson@gmail.com<mailto:jaredhanson@gmail.com>> wrote: > I'm wondering if there is any guidance on including "jku", "jwk", > "x5u", and "x5c" > claims in a JWT/JWS used as a bearer assertion for authentication. > > Specifically, in the case of service-to-service authentication, where > the "iss" is set to the service acting as a client, say > "https://client.example.net/" > making a > request to "https://api.example.com/", and the assertion is signed > using client.example.net's private key. > > In this situation, api.example.com authenticates the assertion by > finding the corresponding public key (possibly in a JWK set, the > location of which can be obtained by something like OpenID Provider > Configuration [1]). > > It is clear that any claims in the assertion are self-asserted until > validated, including both the "iss" and any keys or URLs to keys. > Thus, when a service validates the assertion, it *must not* use the > values of "jku", etc to validate the signature. Instead it should use > some trusted channel to obtain the keys directly from the issuer. > > If this were not done, a malicious entity could freely generate > assertions claiming to be client.example.net, using any private key > and including a malicious reference to its own public key using a > "jku" set to "https://malicious.com/jwks.json" > > This security consideration is not called out anywhere that I've > noticed, which I've seen leading to insecure implementations and/or > bad examples. For example, this example on Gluu's wiki: > http://ox.gluu.org/doku.php?id=oxauth:jwt is blindly using the value > of "jku" to fetch the key used to validate the signature, without any > way to validate that the URL itself belongs to the issuer. > > I'm raising this point hoping that guidance can be clarified and > included in the specification. > > Thanks, > Jared Hanson > > PS. I separately sent this same message to the JOSE list, and later > figured it was equally relevant to OAuth, if not more so. > > [1] > http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConf > ig > > -- > Jared Hanson <http://jaredhanson.net/> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org<mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] Correct use of jku claims in JWT/JWS b… Jared Hanson
- Re: [OAUTH-WG] Correct use of jku claims in JWT/J… Brian Campbell
- Re: [OAUTH-WG] Correct use of jku claims in JWT/J… Mike Jones