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