Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-response-03
Roman Danyliw <rdd@cert.org> Tue, 23 July 2019 00:51 UTC
Return-Path: <rdd@cert.org>
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 E51801200CD for <oauth@ietfa.amsl.com>; Mon, 22 Jul 2019 17:51:10 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 CBaYhIZ5qEAv for <oauth@ietfa.amsl.com>; Mon, 22 Jul 2019 17:51:08 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 9B598120045 for <oauth@ietf.org>; Mon, 22 Jul 2019 17:51:08 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6N0p7ks025616; Mon, 22 Jul 2019 20:51:07 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x6N0p7ks025616
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1563843067; bh=UVZvgSr2pFhxdBRoX34GDkKN6wkncW1g339xQ5G+Bn0=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=posPnzMFaDLoH3+HozS7/ZXxgLkM0C5n6fTa7JXNfDntR8IXZVSrpnj4MLl4W1v4I 39wMHe8c2dceCtRkJY7HUiWGGBQxvrKA0CoBd5Oc6OrvX0VURpkRRsVyf0mRyF1oY/ 3vM10UwyBYI6nymCdk1IvFtK5ce7D7Vu4Ubvp+r4=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6N0p4HA016900; Mon, 22 Jul 2019 20:51:04 -0400
Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Mon, 22 Jul 2019 20:51:03 -0400
From: Roman Danyliw <rdd@cert.org>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
CC: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-response-03
Thread-Index: AdU8um9EYRsZS/zUTimSMgl/pofXXQD431IAABQoH3A=
Date: Tue, 23 Jul 2019 00:51:03 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33E1621@marchand>
References: <359EC4B99E040048A7131E0F4E113AFC01B33D7447@marchand> <271A13CC-5B12-4318-8F3D-9E3ACA6D903E@lodderstedt.net>
In-Reply-To: <271A13CC-5B12-4318-8F3D-9E3ACA6D903E@lodderstedt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/cJeTsAtA28bDArzooHPmZrpahBs>
Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-response-03
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 23 Jul 2019 00:51:11 -0000
Hi Torsten! > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Monday, July 22, 2019 6:59 AM > To: Roman Danyliw <rdd@cert.org> > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection- > response-03 > > Hi Roman, > > thanks a lot for your review feedback. > > I just published a new revision of the draft incorporating changes based on > your comments. > > https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-04 Thanks for the update. I have one refinement below based on the new language around TLS. Details are inline ... > > On 17. Jul 2019, at 18:17, Roman Danyliw <rdd@cert.org> wrote: > > > > Hi! > > > > The following is my AD review of draft-ietf-oauth-jwt-introspection- > response-03. > > > > (1) Section 4. Per introspection_encrypted_response_alg, how is either > signing or encryption being requested? Is it by also including an > introspection_signed_response_alg? If that's the case, it is worth explicitly > saying. > > The response is always signed. The resource server may decide to > additionally turn on encryption. > > Section 3 states “Depending on the specific resource server policy the JWT is > either signed, or signed and encrypted. “ With the new language you added for item #2, I now understand. Thanks for clearing it up. > > (2) Section 4. Per introspection_encrypted_response_enc, I'm having > trouble deconflicting these two sentences: > > > > [1] If "introspection_encrypted_response_alg" is specified, the default for > this value is A128CBC-HS256. > > > > [2] When "introspection_encrypted_response_enc" is included, > "introspection_encrypted_response_alg" MUST also be provided > > > > Sentence [2] explicitly states that "introspection_encrypted_response_alg" > is required. However, the first sentence seems more tentative by saying that > "if introspection_encrypted_response_enc" is present. > > introspection_encrypted_response_enc is optional but must not be > specified without introspection_encrypted_response_alg > > I changed the text to better get this across: > > introspection_encrypted_response_alg > OPTIONAL. JWE algorithm (alg value) as defined in JWA for encrypting > introspection responses. If this is specified, the response will be encrypted > using JWE and the configured algorithm. The default, if omitted, is that no > encryption is performed. If both signing and encryption are requested, the > response will be signed then encrypted, with the result being a Nested JWT, > as defined in JWT. > > introspection_encrypted_response_enc > OPTIONAL. JWE algorithm (enc value) as defined in JWA for authenticated > encryption of introspection responses. The default, if omitted, is A128CBC- > HS256. Note: This parameter MUST NOT be specified without setting > introspection_encrypted_response_alg. Thanks for this new text. It is clearer. > > > > (3) I want to talk through the personally identifiable information being > specified as new introspection fields per Section 8.3 (e.g., name, birthday) > being exposed. I was looking to ensure that it would always be encrypted in > transit (and that only authorized clients could get it). I read that in Section > 3, "[d]epending on the specific resource server policy the JWT is either > signed, or signed and encrypted" and that per Section 4 that "[t]he > authorization server determines what algorithm to employ to secure the > JWT for a particular introspection response." Section 6.2 explicitly notes the > threat of token data leakage (a more general case of my concern so thanks > for that text). [RFC7662], Section 4 notes only that "the server MUST support > Transport Layer Security (TLS) 1.2", but "support" is different than "the > server MUST _use_ TLS". Therefore, it seems like there could be a case where > the server could return an introspection response in the clear (e.g., no TLS, > introspection_sig > > ned_response_alg). Am I missing something? > > > > My bias is to say something on the order of "TLS MUST be used”. > > Section 6.2. now starts with “The authorization server MUST use Transport > Layer Security (TLS) 1.2 (or higher) in order to prevent token data leakage." Works for me to was use TLS. I'd recommend a statement that provides more guidance "The authorization server MUST use Transport Layer Security (TLS) 1.2 (or higher) per RFC7525 in order to prevent token data leakage." > > (4) I also want to talk through an unscrupulous protected resource trying to > harvest introspection meta-data. I was looking for guidance related to the > authorization of the introspection transactions. I found: > > > > Section 2.2 of [RFC7662] says important things like "For instance, an > authorization server MAY limit which scopes from a given token are > returned for each protected resource to prevent a protected resource from > learning more about the larger network than is necessary for its operation." > > > > Section 4 of [RFC7662] says "If left unprotected and un-throttled, the > introspection endpoint could present a means for an attacker to poll a series > of possible token values, fishing for a valid token. To prevent this, the > authorization server MUST require authentication of protected resources > that need to access the introspection endpoint and SHOULD require > protected resources to be specifically authorized to call the introspection > endpoint." > > > > Section 6.2 of this draft provides guidance on defending against > unauthenticated clients. > > > > How does the authorization server restrict a protected resource that _can_ > authenticate to it from getting meta-data is shouldn't have access to? > Something on the order of "the authorization server <uses the following > data> to determine what a given protected resource is allowed to see”. > > I added Section 6.3, which states “The authorisation server determines the > token data a resource server is allowed to see based on the resource server’s > client_id and suitable token data, e.g. the scope value." Great. Thanks for the clarity. > > > > (5) Editorial Nits > > > > ** Section 3. Per "This JWT MAY furthermore contain all other claims > described in Section 2.2. of [RFC7662] and beyond (e.g. as defined in > [OpenID.Core])", would it be more timeless to say the fields specified in > "OAuth Token Introspection Response" registry? > > > > This text pre-dated the addition of the IANA registry section. Thanks for > spotting the inconsistency. > > I modified the text as you suggested. > > > ** Section 4. The first sentence of each parameters descriptions don't > parse -- for example with introspection_signed_response_alg: "JWS > [RFC7515] 'alg' algorithm JWA [RFC7518] REQUIRED", fully expanded that's > "JSON Web Signature (JWS) [RFC7515] "alg" algorithm JSON Web Algorithms > (JWA) [RFC7518] REQUIRED ...". The same is true for the write-ups in Section > 5. > > modfied text > > > > > ** Section 4. Editorial. Per "introspection_encrypted_response_enc": > > s/REQUIRED for encrypting introspection responses/ > > REQUIRED for authenticated encryption of introspection responses/ > > > > done Thanks for all of the above. Regards, Roman > kind regards, > Torsten. > > > > Regards, > > Roman > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-intros… Roman Danyliw
- Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-in… Torsten Lodderstedt
- Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-in… Roman Danyliw
- Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-in… Roman Danyliw
- Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-in… Torsten Lodderstedt
- Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-in… Roman Danyliw
- Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-in… Torsten Lodderstedt