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
> > <[email protected]> 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?
> >
> >
> >
>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
