Re: [OAUTH-WG] Initial JSON Web Token Best Current Practices Draft
Denis <denis.ietf@free.fr> Mon, 05 June 2017 11:31 UTC
Return-Path: <denis.ietf@free.fr>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC2E12948B for <oauth@ietfa.amsl.com>; Mon, 5 Jun 2017 04:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.117
X-Spam-Level:
X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, 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 9rJcnH7lVgJm for <oauth@ietfa.amsl.com>; Mon, 5 Jun 2017 04:31:08 -0700 (PDT)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDF94127419 for <oauth@ietf.org>; Mon, 5 Jun 2017 04:31:07 -0700 (PDT)
Received: from [192.168.0.14] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 05490780383; Mon, 5 Jun 2017 13:31:05 +0200 (CEST)
To: "oauth@ietf.org" <oauth@ietf.org>
References: <CY4PR21MB0504E898E2414522D172663BF5F50@CY4PR21MB0504.namprd21.prod.outlook.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <178f2f7c-a12e-234d-72aa-9d49d8621489@free.fr>
Date: Mon, 05 Jun 2017 13:31:06 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <CY4PR21MB0504E898E2414522D172663BF5F50@CY4PR21MB0504.namprd21.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------A3A3A43D55B0EA61E0094038"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/5NwUzaXGcM-q8BiBWb0_GiTkpnI>
Subject: Re: [OAUTH-WG] Initial JSON Web Token Best Current Practices Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 05 Jun 2017 11:31:11 -0000
Comments on draft-sheffer-oauth-jwt-bcp-00 1. Section 2 lists 7 known and possible threats and vulnerabilities with JWT implementations and deployments. In the OAuth Threat Model Document (RFC 6819) collusions between users located inside of a system are not mentioned but nevertheless need to be considered. One threat should be added in this document: Client collusions Text proposal: 2.8 Client collusions RFC 6819 (OAuth 2.0 Threat Model and Security Considerations) issued in January 2013 identifies security threats coming from hostile parties but does not mention threats coming from collaborating parties. JWTs are issued to a token requestor and are normally intended to be used by that token requestor. They are cases where the forwarding of a JWT to another party is a desirable property so that it can be used by that other party. This is typically the case when a JWT is intended to be used for delegation purposes. However, there are cases where a JWT does not contain a "sub" claim, but other claims that do not allow to identify the token requestor. This is typically the case when a JWT contains an attribute specifying that the token holder is over 18. In such a case, the forwarding of such a JWT to another party would not be a desirable property and should be detected by target servers. Access token binding protection methods currently developed either by the Token Binding WG [Token Binding WG] or by the OAuth WG [OAuth WG] do not allow to counter the forwarding of a JWT legitimately obtained by a party to another party. Either the legitimate party can provide keys to the other party, or if it can't (because private keys are protected by a secure element) it can send requests to his secure element to perform the cryptographic computations that the other party needs. Whatever kind of cryptographic is being used, when two parties are willing to collaborate, a software-only solution will be unable to prevent the transfer of an attribute of a party that possesses it to another party that does not possess it. The use of a secure element will be mandatory. However, the use of a secure element simply protecting the confidentiality and the integrity of some secret key or private key will be insufficient. Additional functional and security properties will be required for the secure elements. The documents related to OAuth 2.0 do not currently specify how to support secure elements so that the forwarding of a JWT legitimately obtained by a party to another party can be detected by the target server. Unless some extensions are being defined, the OAuth 2.0 framework will be unable to support JWTs containing attributes that do not allow to fully identify the token holder, typically a single attribute specifying that the token holder is over 18. 2. Section 3 lists some best practices. Section 3.8 is written as follows: 3.8. Use and Validate Audience If the same issuer can issue JWTs that are intended for use by more than one relying party or application, the JWT MUST contain an "aud" (audience) claim that can be used to determine whether the JWT is being used by an intended party or was substituted by an attacker at an unintended party. JWTs may be used in a number of contexts, in particular when the resource owner and the target server are not collocated. If the resource or the audience parameter is being used, the STS will have the ability to know exactly which individual or entity has accessed which target service and may keep a log of that activity. It would thus be in a position to act as Big Brother. Mandating implementations to have built-in Big Brother properties does not seem to be a "good practice". However, there is indeed the need to restrict the use of JWTs to specific targets. The key point is that the target service must be able to recognize itself that the token is indeed targeted to it. As an example, a challenge may be requested to the target service and that challenge may then be placed into a specific filed of the JWT. The target service may then verify that the value included in the JWT is the one that has been recently provided. A parameter specifying the type of the control value and the value of the control would need to be used. This parameter would be called a target_id (tid). It would solve the Big Brother case. This parameter cannot be introduced in a BCP document, but this should be done in another document. When the resource owner and the target server are not collocated and when privacy is a concern, the use of these parameters should be deprecated and the use of a "tid" parameter should be recommended. In any case, stating that "the JWT MUST contain an "aud" (audience) claim" is incorrect. Denis > JSON Web Tokens (JWTs) and the JSON Object Signing and Encryption > (JOSE) functions underlying them are now being widely used in diverse > sets of applications. During IETF 98 in Chicago > <https://ietf.org/meeting/98/>, we discussed reports of people > implementing and using JOSE and JWTs insecurely, the causes of these > problems, and ways to address them. Part of this discussion was an > invited JOSE/JWT Security Update > <https://www.ietf.org/proceedings/98/slides/slides-98-oauth-sessb-jwt-security-update-00.pdf> > presentation that I gave to two working groups, which included links > to problem reports and describes mitigations. Citing the widespread > use of JWTs in new IETF applications, Security Area Director Kathleen > Moriarty suggested during these discussions that a Best Current > Practices (BCP) document be written for JSON Web Tokens (JWTs). > > I’m happy to report that Yaron Sheffer, Dick Hardt, and myself have > produced an initial draft of a JWT BCP. Its abstract is: > > JSON Web Tokens, also known as JWTs [RFC7519 > <https://tools.ietf.org/html/rfc7519>], are URL-safe JSON-based > security tokens that contain a set of claims that can be signed and/or > encrypted. JWTs are being widely used and deployed as a simple > security token format in numerous protocols and applications, both in > the area of digital identity, and in other application areas. The goal > of this Best Current Practices document is to provide actionable > guidance leading to secure implementation and deployment of JWTs. > > In Section 2, we describe threats and vulnerabilities. In Section 3, > we describe best practices addressing those threats and > vulnerabilities. We believe that the best practices in Sections 3.1 > through 3.8 are ready to apply today. Section 3.9 (Use Mutually > Exclusive Validation Rules for Different Kinds of JWTs) describes > several possible best practices on that topic to serve as a starting > point for a discussion on which of them we want to recommend under > what circumstances. > > We invite input from the OAuth Working Group and other interested > parties on what best practices for JSON Web Tokens and the JOSE > functions underlying them should be. We look forward to hearing your > thoughts and working on this specification together. > > The specification is available at: > > * https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-00 > > An HTML-formatted version is also available at: > > * http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-00.html > > -- Mike > > P.S. This notice was also posted at http://self-issued.info/?p=1690 > <http://self-issued.info/?p=1690> and as @selfissued > <https://twitter.com/selfissued>. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] Initial JSON Web Token Best Current Pr… Mike Jones
- Re: [OAUTH-WG] Initial JSON Web Token Best Curren… Neil Madden
- Re: [OAUTH-WG] Initial JSON Web Token Best Curren… Denis
- Re: [OAUTH-WG] Initial JSON Web Token Best Curren… Denis
- Re: [OAUTH-WG] Initial JSON Web Token Best Curren… Neil Madden
- Re: [OAUTH-WG] Initial JSON Web Token Best Curren… Yaron Sheffer
- Re: [OAUTH-WG] Initial JSON Web Token Best Curren… Neil Madden