Please unsubscribe me from your mailing list Isaac O.Ajonibode C.Director CBMC Nigeria cbmcnigeria2...@gmail.com www.cbmcint.com/Nigeria +2347087552127
FOUNDER/CEO AJOFOLU VENTURES INT'L LTD ajofoluventu...@gmail.com +2348164286235 2 Corinthians 5:20 On Mon, 2 Mar 2020, 06:33 , <oauth-requ...@ietf.org> wrote: > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-requ...@ietf.org > > You can reach the person managing the list at > oauth-ow...@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: Benjamin Kaduk's Discuss on > draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and > COMMENT) (Benjamin Kaduk) > 2. Re: OAuth 2.0 Token Introspection in RFC7662 : Refresh token? > (David Waite) > 3. Re: OAuth 2.0 Token Introspection in RFC7662 : Refresh token? > (Andrii Deinega) > 4. Re: OAuth 2.0 Token Introspection in RFC7662 : Refresh token? > (David Waite) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 1 Mar 2020 17:03:41 -0800 > From: Benjamin Kaduk <ka...@mit.edu> > To: Torsten Lodderstedt <tors...@lodderstedt.net> > Cc: The IESG <i...@ietf.org>, > draft-ietf-oauth-jwt-introspection-respo...@ietf.org, > oauth-cha...@ietf.org, oauth <oauth@ietf.org>, Rifaat Shekh-Yusef > <rifaat.i...@gmail.com>, Roman Danyliw <r...@cert.org> > Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on > draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and > COMMENT) > Message-ID: <20200302010341.gz98...@kduck.mit.edu> > Content-Type: text/plain; charset=utf-8 > > On Fri, Feb 28, 2020 at 03:44:05PM +0100, Torsten Lodderstedt wrote: > > Hi Ben, > > > > > On 25. Feb 2020, at 23:52, Benjamin Kaduk via Datatracker < > nore...@ietf.org> wrote: > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-oauth-jwt-introspection-response-08: Discuss > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut this > > > introductory paragraph, however.) > > > > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ > > > > > > > > > > > > > This post focuses on clarifying your DISCUSS comments in order to get > the process moving again. > > > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > > Thank you for the updates in the -08; they address the bulk of the > > > substantive issues! I have a few points remaining on the -08 text but > I > > > think there are more localized issues to resolve. > > > > > > Can IANA please confirm that the new allocations in the -08 have > > > received appropriate Expert (e.g., media type) review? I see some > > > updates in the datatracker history relating to the -08 but nothing in > > > the email archives. > > > > > > It looks like we need to register 'active' as a JWT claim? > > > > That?s correct. Will add this. > > > > > > > > I don't think the new semantics for "jti" in the introspection response > > > are compatible with the RFC 7519 definition. Specifically, we say that > > > "jti" will be tied to the input access token, but 7519 says that "jti" > > > has to change when the contents of the JWT change ("MUST be assigned in > > > a manner that ensures that there is a negligible probability that the > > > same value will be accidentally assigned to a different data object"), > > > and we admit at least the possibility of "active" and "iat" changing. > > > > I think the key word is ?accidentally?. This spec causes the AS to > purposefully issue JWTs with the same ?jti? in order to allow replay > detection with respect to the introspected access token. ?iat? is changed > in order to give the RS an indication and proof when the introspection > response was minted by the AS. > > I think "accidentally" is just there to emphasize that there's a risk of > accidental collision when using a random string as an identifier, since "of > course you wouldn't deliberately reuse a token identifier". This stance > seems to supported by "[t]he 'jti' (JWT ID) claim provides a unique > identifier for the JWT". It's really hard for me to read that sentence as > allowing the use of a single identifier for two different JWT values, since > it then ceases to be a *unique* identifier. > > I seem to have forgotten how this replay detection is supposed to work; > would you mind giving me a pointer and/or refresher? > > > > > ?Active" does not really change, since the introspection response of an > inactive token is empty except the ?active? element. > > I mean, the token artifact still changes. What am I supposed to interpret > "the JWT" as meaning if not the actual encoded artifact? > > > So I don?t see issues regarding RFC 7519. > > > > > > > > Section 5 says that: > > > > > > If the access token is considered active, it MUST contain the claims > > > "iss" and "aud" in order to prevent misuse of the JWT as an ID or > > > access token (see Section 8.1). > > > > > > But I don't think the predicate is correct -- misuse is still possible > > > by services that do not check the "active" claim's value. Shouldn't > the > > > "iss"+"aud" requirements be unconditional? > > > > Introspection responses for inactive tokens won?t contain any data > except ?active?:false. I don?t see how they could be misused and therefore > think the text is ok. > > Could you give me a pointer where in the text it says that if "active" is > false, no other claims are present? ("active" only appears three times, > but none of them seem to say this.) > > -Ben > > > Please let me know whether you agree with my statements. I would then > quickly publish a new revision (including changes to address your comments). > > > > best regards, > > Torsten. > > > > > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > [New comments on the added text in the diff from -07 to -08.] > > > > > > Section 3 > > > > > > To support encrypted token introspection response JWTs, the > > > authorization server MUST also be provided with the respective > > > resource server encryption keys and algorithms. > > > > > > IIRC, based on some list discussion this text was going to be tweaked > to > > > avoid implying that JWE is mandatory. (Unfortunately, this is the > > > thread that evolved into "client certs and TLS Terminating Reverse > > > Proxies", so it's hard to be sure whether I saw any other followups.) > > > > > > The AS MUST restrict the use of client credentials by a RS to the > > > calls it requires, e.g. the AS MAY restrict such a client to call the > > > token introspection endpoint only. How the AS implements this > > > restriction is beyond the scope of this specification. > > > > > > This should probably be clarified a bit more, in the context of "client > > > credentials tend to be used by privileged, fixed endpoints, and the > > > default may just be to allow them all access to all endpoints". Right > > > now it's not clear what's being restricted (and who "it" is that > > > requires calls) > > > > > > Section 5 > > > > > > This specification registers the "application/token- > > > introspection+jwt" media type, which is used as value of the "typ" > > > header parameter of the JWT to indicate that the payload is a token > > > introspection response. > > > > > > Do we also want to note that checking 'jti' is not mandatory and so > this > > > does not necessarily provide full protection? (I guess Section 8.1 > > > covers this in more detail.) > > > > > > The value of the "aud" claims MUST identify the resource server > > > receiving the token introspection response. > > > > > > We may want to dig into this a bit more: should there be any > > > relationship between this "aud" value and the "client_id" that an RS > > > might be using (as obtained from dynamic registration)? > > > Does this value need to be different from the audience that is used in > > > access tokens for which this RS is the audience? (Should it be the > > > same?) My instincts lean towards "different" but I would like broader > > > input. > > > > > > exp The "exp" claim indicates when the access token passed in the > > > introspection request will expire. > > > > > > On the face of it this seems divergent from RFC 7519's "the expiration > > > time on or after which the JWT MUST NOT be accepted for processing", > > > though upon further examination the distinction is not quite so large. > > > That is, it's in effect saying that the introspection response should > > > not be accepted for processing after the base token has expired, which > > > usually makes sense. There is a bit of a complication, though, in that > > > the "active" claim implies that we might still have RSes that plan to > > > use the introspection response after the "exp" date has passed, which > > > sounds a lot like a DISCUSS-level internal inconsistency. > > > > > > If possible, the AS MUST narrow down the "scope" value to the scopes > > > relevant to the particular RS. > > > > > > This sounds kind of like a "SHOULD"... > > > > > > The example response header contains the following JSON document: > > > > > > I think this is the JOSE header in the HTTP response (body), not the > > > (HTTP) response header. > > > > > > Section 8.1 > > > > > > As an alternative approach, such an attack can be prevented like any > > > other token substitution attack by restricting the audience of the > > > > > > I'd suggest avoiding describing these as "alternatives"; they seem more > > > like complementary approaches as part of a defense-in-depth solution > > > (especially since we are basically mandating both of them). > > > > > > "aud" value set to the resource server's identifier. Any recipient > > > of an JWT MUST check these values in order to detect substitution > > > attacks. > > > > > > This "MUST" might be out of place -- this is a requirement from RFC > > > 7519, and not an attempt by this document to make new requirements on > > > the behavior of all JWT consumers (if it was, that would be a DISCUSS > > > point!). > > > > > > Resource servers MUST additionally apply the countermeasures against > > > replay as described in [I-D.ietf-oauth-security-topics], section 3.2. > > > > > > In a similar vein, which set of resources servers is this normative > > > "MUST" intended to be binding upon? > > > > > > Section 9 > > > > > > In any case, the AS MUST ensure that the scope of the legal basis is > > > enforced throughout the whole process. The AS MUST retain the scope > > > of the legal basis with the access token, e.g. in the scope value, > > > and the AS MUST determine the data a resource server is allowed to > > > receive based on the resource server's identity and suitable token > > > data, e.g. the scope value. > > > > > > I suspect I'm just being dense, but could you walk me through how the > > > access token "scope" value can encode the legal basis for data > transfer? > > > > > > > > > > > > > > > > ------------------------------ > > Message: 2 > Date: Sun, 1 Mar 2020 20:38:45 -0700 > From: David Waite <da...@alkaline-solutions.com> > To: Andrii Deinega <andrii.dein...@gmail.com> > Cc: Bill Jung <bjung=40pingidentity....@dmarc.ietf.org>, > oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : > Refresh token? > Message-ID: > <c0c40a3e-2455-4c86-b504-ab18f3197...@alkaline-solutions.com> > Content-Type: text/plain; charset=us-ascii > > I would expect the AS to invalidate the refresh token in this case, which > would not require a refresh token mode nor necessarily any signaling back > to the resource. > > -DW > > > On Mar 1, 2020, at 12:12 AM, Andrii Deinega <andrii.dein...@gmail.com> > wrote: > > > > Hello Bill, > > > > I'm just thinking out loud about possible scenarios for a protected > > resource here... It may decide to revoke a refresh token if a client > > application tried to use it instead of an access token when the > > protected resource is paranoid about security. In order to do that an > > introspection response should include a non-standard parameter which > > indicates that the requested token is refresh_token. > > > > A user of the introspection endpoint should rely only on a value of > > the active parameter (which is a boolean indicator) of the endpoint > > response. This applies to both types of tokens. Note, the expiration > > date, as well as other parameters, are defined as optional in the > > specification. Both token types can be revoked before the expiration > > date comes even if this parameter is presented as part of the > > response. In my opinion, there are a number of reasons why this check > > (for a refresh token) can be useful on the client application side. > > > > -- > > Regards, > > Andrii > > > > > > On Fri, Feb 28, 2020 at 1:59 AM Bill Jung > > <bjung=40pingidentity....@dmarc.ietf.org> wrote: > >> > >> Hello, hopefully I am using the right email address. > >> > >> Simply put, can this spec be enhanced to clarify "Who can use the > introspection endpoint for a refresh token? A resource provider or a client > app or both?" > >> > >> RFC7662 clearly mentions that the user of introspection endpoint is a > 'protected resource' and that makes sense for an access token. If we allow > this to client apps, it'll give unnecessary token information to them. > >> However, the spec also mentions that refresh tokens can also be used > against the endpoint. > >> In case of refresh tokens, user of the endpoint should be a client app > because refresh tokens are used by clients to get another access token. > (Cannot imagine how/why a resource server would introspect a refresh token) > >> > >> Is it correct to assume that the endpoint should be allowed to client > apps if they want to examine refresh token's expiry time? Then the RFC > should clearly mention it. > >> > >> Thanks in advance. > >> > >> <Details from the spec> > >> In https://tools.ietf.org/html/rfc7662 > >> In '1. Introduction' section says, > >> "This specification defines a protocol that allows authorized > >> protected resources to query the authorization server to determine > >> the set of metadata for a given token that was presented to them by > >> an OAuth 2.0 client." > >> Above makes clear that user of the endpoint is a "protected resource". > >> > >> And under 'token' in '2.1. Introspection Request' section says, > >> "For refresh tokens, > >> this is the "refresh_token" value returned from the token endpoint > >> as defined in OAuth 2.0 [RFC6749], Section 5.1." > >> So looks like a refresh token is allowed for this endpoint. > >> > >> > >> Bill Jung > >> Manager, Response Engineering > >> bj...@pingidentity.com > >> w: +1 604.697.7037 > >> Connect with us: > >> > >> CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you._______________________________________________ > >> 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 > > > > ------------------------------ > > Message: 3 > Date: Sun, 1 Mar 2020 21:11:40 -0800 > From: Andrii Deinega <andrii.dein...@gmail.com> > To: David Waite <da...@alkaline-solutions.com> > Cc: Bill Jung <bjung=40pingidentity....@dmarc.ietf.org>, > oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : > Refresh token? > Message-ID: > <CALkShct=sYSq-HoG=yMiV2BqT8+F= > gnej+p2ggfd87fv1oq...@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > How would the authorization server know who actually uses the > introspection endpoint assuming that a protected resource and a client > application use the same credentials (client_id and client_secret)? > > Regards, > Andrii > > On Sun, Mar 1, 2020 at 7:38 PM David Waite <da...@alkaline-solutions.com> > wrote: > > > > I would expect the AS to invalidate the refresh token in this case, > which would not require a refresh token mode nor necessarily any signaling > back to the resource. > > > > -DW > > > > > On Mar 1, 2020, at 12:12 AM, Andrii Deinega <andrii.dein...@gmail.com> > wrote: > > > > > > Hello Bill, > > > > > > I'm just thinking out loud about possible scenarios for a protected > > > resource here... It may decide to revoke a refresh token if a client > > > application tried to use it instead of an access token when the > > > protected resource is paranoid about security. In order to do that an > > > introspection response should include a non-standard parameter which > > > indicates that the requested token is refresh_token. > > > > > > A user of the introspection endpoint should rely only on a value of > > > the active parameter (which is a boolean indicator) of the endpoint > > > response. This applies to both types of tokens. Note, the expiration > > > date, as well as other parameters, are defined as optional in the > > > specification. Both token types can be revoked before the expiration > > > date comes even if this parameter is presented as part of the > > > response. In my opinion, there are a number of reasons why this check > > > (for a refresh token) can be useful on the client application side. > > > > > > -- > > > Regards, > > > Andrii > > > > > > > > > On Fri, Feb 28, 2020 at 1:59 AM Bill Jung > > > <bjung=40pingidentity....@dmarc.ietf.org> wrote: > > >> > > >> Hello, hopefully I am using the right email address. > > >> > > >> Simply put, can this spec be enhanced to clarify "Who can use the > introspection endpoint for a refresh token? A resource provider or a client > app or both?" > > >> > > >> RFC7662 clearly mentions that the user of introspection endpoint is a > 'protected resource' and that makes sense for an access token. If we allow > this to client apps, it'll give unnecessary token information to them. > > >> However, the spec also mentions that refresh tokens can also be used > against the endpoint. > > >> In case of refresh tokens, user of the endpoint should be a client > app because refresh tokens are used by clients to get another access token. > (Cannot imagine how/why a resource server would introspect a refresh token) > > >> > > >> Is it correct to assume that the endpoint should be allowed to client > apps if they want to examine refresh token's expiry time? Then the RFC > should clearly mention it. > > >> > > >> Thanks in advance. > > >> > > >> <Details from the spec> > > >> In https://tools.ietf.org/html/rfc7662 > > >> In '1. Introduction' section says, > > >> "This specification defines a protocol that allows authorized > > >> protected resources to query the authorization server to determine > > >> the set of metadata for a given token that was presented to them by > > >> an OAuth 2.0 client." > > >> Above makes clear that user of the endpoint is a "protected resource". > > >> > > >> And under 'token' in '2.1. Introspection Request' section says, > > >> "For refresh tokens, > > >> this is the "refresh_token" value returned from the token endpoint > > >> as defined in OAuth 2.0 [RFC6749], Section 5.1." > > >> So looks like a refresh token is allowed for this endpoint. > > >> > > >> > > >> Bill Jung > > >> Manager, Response Engineering > > >> bj...@pingidentity.com > > >> w: +1 604.697.7037 > > >> Connect with us: > > >> > > >> CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you._______________________________________________ > > >> 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 > > > > > > ------------------------------ > > Message: 4 > Date: Sun, 1 Mar 2020 22:33:22 -0700 > From: David Waite <da...@alkaline-solutions.com> > To: Andrii Deinega <andrii.dein...@gmail.com> > Cc: Bill Jung <bjung=40pingidentity....@dmarc.ietf.org>, > oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : > Refresh token? > Message-ID: > <d3d1bfb8-ce54-4e48-a8b9-45e01ed2b...@alkaline-solutions.com> > Content-Type: text/plain; charset=us-ascii > > On Mar 1, 2020, at 10:11 PM, Andrii Deinega <andrii.dein...@gmail.com> > wrote: > > > > How would the authorization server know who actually uses the > > introspection endpoint assuming that a protected resource and a client > > application use the same credentials (client_id and client_secret)? > > In the external context, you have a client accessing a protected resource > with an access token. The client should treat the token as opaque, and > RFC7662 makes no allowances for that client to introspect its tokens. > > If you control both the client and protected resource, you may decide to > short-cut and have them share credentials. However, the client logic still > should never be introspecting the tokens. > > The security considerations also say that you must prove the > authentication of the protected resource, which I have interpreted to mean > that access tokens used to authorize the call to the introspection endpoint > must be issued to a confidential client - public clients cannot protect > credentials to perform an authentication. You want to limit introspection > to prevent denial of service and probing attacks, and to limit the amount > of information on viable attacks conveyed if someone steals a token. > > -DW > > > > > Regards, > > Andrii > > > > On Sun, Mar 1, 2020 at 7:38 PM David Waite <da...@alkaline-solutions.com> > wrote: > >> > >> I would expect the AS to invalidate the refresh token in this case, > which would not require a refresh token mode nor necessarily any signaling > back to the resource. > >> > >> -DW > >> > >>> On Mar 1, 2020, at 12:12 AM, Andrii Deinega <andrii.dein...@gmail.com> > wrote: > >>> > >>> Hello Bill, > >>> > >>> I'm just thinking out loud about possible scenarios for a protected > >>> resource here... It may decide to revoke a refresh token if a client > >>> application tried to use it instead of an access token when the > >>> protected resource is paranoid about security. In order to do that an > >>> introspection response should include a non-standard parameter which > >>> indicates that the requested token is refresh_token. > >>> > >>> A user of the introspection endpoint should rely only on a value of > >>> the active parameter (which is a boolean indicator) of the endpoint > >>> response. This applies to both types of tokens. Note, the expiration > >>> date, as well as other parameters, are defined as optional in the > >>> specification. Both token types can be revoked before the expiration > >>> date comes even if this parameter is presented as part of the > >>> response. In my opinion, there are a number of reasons why this check > >>> (for a refresh token) can be useful on the client application side. > >>> > >>> -- > >>> Regards, > >>> Andrii > >>> > >>> > >>> On Fri, Feb 28, 2020 at 1:59 AM Bill Jung > >>> <bjung=40pingidentity....@dmarc.ietf.org> wrote: > >>>> > >>>> Hello, hopefully I am using the right email address. > >>>> > >>>> Simply put, can this spec be enhanced to clarify "Who can use the > introspection endpoint for a refresh token? A resource provider or a client > app or both?" > >>>> > >>>> RFC7662 clearly mentions that the user of introspection endpoint is a > 'protected resource' and that makes sense for an access token. If we allow > this to client apps, it'll give unnecessary token information to them. > >>>> However, the spec also mentions that refresh tokens can also be used > against the endpoint. > >>>> In case of refresh tokens, user of the endpoint should be a client > app because refresh tokens are used by clients to get another access token. > (Cannot imagine how/why a resource server would introspect a refresh token) > >>>> > >>>> Is it correct to assume that the endpoint should be allowed to client > apps if they want to examine refresh token's expiry time? Then the RFC > should clearly mention it. > >>>> > >>>> Thanks in advance. > >>>> > >>>> <Details from the spec> > >>>> In https://tools.ietf.org/html/rfc7662 > >>>> In '1. Introduction' section says, > >>>> "This specification defines a protocol that allows authorized > >>>> protected resources to query the authorization server to determine > >>>> the set of metadata for a given token that was presented to them by > >>>> an OAuth 2.0 client." > >>>> Above makes clear that user of the endpoint is a "protected resource". > >>>> > >>>> And under 'token' in '2.1. Introspection Request' section says, > >>>> "For refresh tokens, > >>>> this is the "refresh_token" value returned from the token endpoint > >>>> as defined in OAuth 2.0 [RFC6749], Section 5.1." > >>>> So looks like a refresh token is allowed for this endpoint. > >>>> > >>>> > >>>> Bill Jung > >>>> Manager, Response Engineering > >>>> bj...@pingidentity.com > >>>> w: +1 604.697.7037 > >>>> Connect with us: > >>>> > >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you._______________________________________________ > >>>> 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 > >> > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 137, Issue 4 > ************************************* >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
