Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-response-03
Torsten Lodderstedt <torsten@lodderstedt.net> Tue, 23 July 2019 21:06 UTC
Return-Path: <torsten@lodderstedt.net>
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 365381209B9 for <oauth@ietfa.amsl.com>; Tue, 23 Jul 2019 14:06:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 ea82XN302tWz for <oauth@ietfa.amsl.com>; Tue, 23 Jul 2019 14:06:10 -0700 (PDT)
Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.98]) (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 5CC8C1209B2 for <oauth@ietf.org>; Tue, 23 Jul 2019 14:06:09 -0700 (PDT)
Received: from [84.158.229.114] (helo=[192.168.71.123]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <torsten@lodderstedt.net>) id 1hq1z3-0002WE-41; Tue, 23 Jul 2019 23:06:05 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <D8687765-A3CA-499A-B7DD-CB7C341E71B9@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_98F76ADD-84A0-418D-85E0-31450F99FCFB"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 23 Jul 2019 23:06:04 +0200
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B33E1631@marchand>
Cc: "oauth@ietf.org" <oauth@ietf.org>, Vladimir Dzhuvinov <vladimir@connect2id.com>
To: Roman Danyliw <rdd@cert.org>
References: <359EC4B99E040048A7131E0F4E113AFC01B33D7447@marchand> <271A13CC-5B12-4318-8F3D-9E3ACA6D903E@lodderstedt.net> <359EC4B99E040048A7131E0F4E113AFC01B33E1621@marchand> <359EC4B99E040048A7131E0F4E113AFC01B33E1631@marchand>
X-Mailer: Apple Mail (2.3445.104.11)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/iCgLUQoSCVZY6FQy9z4NGLvk9w0>
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 21:06:23 -0000
Hi Roman, the latest revision -05 should address all points you raised. https://www.ietf.org/id/draft-ietf-oauth-jwt-introspection-response-05.txt kind regards, Torsten. > On 23. Jul 2019, at 02:56, Roman Danyliw <rdd@cert.org> wrote: > > Hi Torsten! > > Separately from the below, idnits is troubled by the lack of an RFC2119 section and the presence or absence of some reference despite citation: > > ==[ snip ]== > > Miscellaneous warnings: > ---------------------------------------------------------------------------- > > == The document seems to lack the recommended RFC 2119 boilerplate, even if > it appears to use RFC 2119 keywords. > > (The document does seem to have the reference to RFC 2119 which the > ID-Checklist requires). > > Checking references for intended status: Proposed Standard > ---------------------------------------------------------------------------- > > (See RFCs 3967 and 4897 for information about using normative references > to lower-maturity documents in RFCs) > > == Missing Reference: 'RFC5322' is mentioned on line 471, but not defined > > == Missing Reference: 'RFC3966' is mentioned on line 537, but not defined > > == Missing Reference: 'RFC4627' is mentioned on line 562, but not defined > > ** Obsolete undefined reference: RFC 4627 (Obsoleted by RFC 7159) > > == Unused Reference: 'RFC2119' is defined on line 606, but no explicit > reference was found in the text > > == Unused Reference: 'RFC2246' is defined on line 611, but no explicit > reference was found in the text > > == Outdated reference: A later version (-06) exists of > draft-ietf-oauth-jwt-bcp-04 > > == Outdated reference: A later version (-13) exists of > draft-ietf-oauth-security-topics-11 > > ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) > ==[ snip ]== > > Roman > >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Roman Danyliw >> Sent: Monday, July 22, 2019 8:51 PM >> To: Torsten Lodderstedt <torsten@lodderstedt.net> >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection- >> response-03 >> >> 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-respons >>> e-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 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