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-boun...@ietf.org] On Behalf Of Roman Danyliw
> Sent: Monday, July 22, 2019 8:51 PM
> To: Torsten Lodderstedt <tors...@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:tors...@lodderstedt.net]
> > Sent: Monday, July 22, 2019 6:59 AM
> > To: Roman Danyliw <r...@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 <r...@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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
