Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Nat,

Also inline.

On Thu, Aug 13, 2020 at 11:25:27PM +0900, Nat Sakimura wrote:
>    Thanks Benjamin. 
>    My replies inline below: 
>    On Wed, Aug 12, 2020 at 12:53 AM Benjamin Kaduk via Datatracker
>    <[e-mail]> wrote:
> 
>      Benjamin Kaduk has entered the following ballot position for
>      draft-ietf-oauth-jwsreq-26: No Objection
> 
>      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-jwsreq/
> 
>      ----------------------------------------------------------------------
>      COMMENT:
>      ----------------------------------------------------------------------
> 
>      Thanks for the many updates as we worked through the issues.
> 
>      Let's also add a note about "whose JWT Claims Set holds the JSON encoded
>      OAuth 2.0 authorization request parameters" to the definition of Request
>      Object in Section 2.1 (in addition to the note in the Introduction); my
>      apologies for not including that when I suggested the change to the
>      Introduction.
> 
>    Sure. Thanks for pointing out.  
> 
>      Please update the Content-Length in the example in Section 5.2.3.
> 
>    Ditto. 

Thanks for both of these.

> 
>      Section 4
> 
>         The client determines the algorithms used to sign and encrypt request
>         objects.  This decision can be based on metadata the client
>         registered via dynamic client registration [RFC7591] using the
>         parameters "request_object_signing_alg",
>         "request_object_encryption_alg", "request_object_encryption_enc" as
>         defined in the the IANA "OAuth Dynamic Client Registration Metadata"
>         registry [IANA.OAuth.Parameters] established by [RFC7591].
> 
>      I had to read this ("this decision can be based on [...]") a few times
>      to understand it.  If I understand correctly, the idea is that the
>      client will register with the AS the keys it will use for constructing
>      the JAR, and in that way the AS has a binding from JAR-signing key to
>      the specific client and request.  So it's true that the decision of what
>      key to use "can be based on" the metadata that the client registered, in
>      that deciding to use a different key than the registered one(s) is
>      likely to cause the AS to reject the request, but that's perhaps not the
>      main point.  Would it work to instead just say that "The keys used to
>      sign and encrypt request objects (and thus, the algorithms that can be
>      used with those keys) can be registered via dynamic client registration
>      [...]"?
> 
>    This paragraph is just talking about the algorithms and not the keys
>    themselves. 
>    Keys are obtained through jwks_uri registered through the dynreg. 
>    It could have multiple keys in it. 
>    This paragraph is in some sense putting constraints on what algorithms the
>    client can choose. 
>    I agree that the sentence is super long and difficult to parse. 
>    I will think about the way to rephrase. 

Okay.  (I do not have any good ideas right now.)

> 
>      Section 5.2
> 
>         The contents of the resource referenced by the URI MUST be a Request
>         Object, unless the URI was provided to the client by the
>         Authorization Server.  The "request_uri" value MUST be either URN as
>         defined in RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of
>         RFC7230 [RFC7230] .  The "request_uri" value MUST be reachable by the
>         Authorization Server.
> 
>      I defer to my ART-area colleagues, but I'm not sure what it means for a
>      URN URI to be "reachable"; is this requirement intended to only apply to
>      the "https:" case?
> 
>    Again, it may be a phrasing problem, but the AS need to be able to obtain
>    the content of the request object that is represented by the URN. That's
>    what it is being expressed by "reachable". If there is a better
>    expression, I am open to adopting it.  

Oops, I see my question was badly written.  There are three relevant
choices/distinctions, but I assumed only two when I wrote the above.

(1) Is the URI provided to the client by the AS or not
(2) Is the "request_uri" a URN or an "https" URI
(3) Is the "request_uri" value reachable by the AS

I asked how (3) related to (2), but really I meant to ask how (3) related
to (1).  That is, if the AS provides the URI, in some sense there does not
need to be an "actual resource" that would be "reachable" by someone with
the URI.  However, the answer to (2) seems to be independent of the answer
to (1), in that a URI not provided by the AS can still be a URN, so the
requirement of reachability will apply regardless of the answer to question
(2).  Accordingly, I no longer think there's an opportunity for tightening
up the description here.  Sorry for the noise!


>      Section 5.2.1
> 
>         It is possible for the Request Object to include values that are to
>         be revealed only to the Authorization Server.  As such, the
>         "request_uri" MUST have appropriate entropy for its lifetime.  For
> 
>      Is there a good reference for what the lifetime of such a request might
>      be?  Perhaps I've been reading too much of GNAP, but my intuition is
>      that much of the time these requests will be single-use, and I don't
>      have as clear of a picture for when they might persist longer.  There
>      are also potential security considerations for long-lived request
>      objects, in terms of making sure that there is a binding between the
>      client's intent to use a given request object for a given request, the
>      user's authorization, etc.
> 
>    This can actually be use-case dependent. 
>    In the majority of the case, it will be pretty short. 
>    But at the time, it may be possible for the client to push the request
>    object to the AS not by the user action but on its own and wait for user
>    action after notifying the user. In such a case, it could be pretty long,
>    I imagine. 

Ah, I see; thanks.

> 
>      Section 5.2.3
> 
>      (side note) I'd consider updating the timestamps in the example response
>      (and perhaps moving to Apache 2.4+ as well?).
> 
>    OK. Good point. 
>     
> 
>      Section 6.x
> 
>      (nit) I suggest consistency in subsection headings, so, e.g., "JWE
>      Encrypted Request Object" and "JWS Signed Request Object".
> 
>    Good point. 
>     
> 
>      Section 6.2
> 
>         The Authorization Server MUST perform the signature validation of the
>         JSON Web Signature [RFC7515] signed request object.  For this, the
>         "alg" Header Parameter in its JOSE Header MUST match the value of the
>         pre-registered algorithm.  The signature MUST be validated against
>         the appropriate key for that "client_id" and algorithm.
> 
>      This text suggests that pre-registration is mandatory, whereas up in
>      Section 4 the client's choice of algorithm was merely something that
>      "can be based on [metadata registered via dynamic registration]".  I
>      know that dynamic registration is not the only kind of registration
>      possible, but we may want to wordsmith one (or both) location to improve
>      the consistency.
> 
>    Good point. I will work on it but also I would welcome a concrete proposal
>    on it as well. 

I am not 100% sure I know or remember all the relevant details, but to talk
through a few things: IIUC, some form of client registration is required,
since for a public client we don't have any credentials that would make the
request object usable.  This means that we require either static
provisioning or dynamic registration, in which case section 4 could talk
about something like "this decision can be based on metadata the client
registered via dynamic client registration [...] or statically provisioned
along with the client's registration at the AS".

> 
>      Section 6.3
> 
>      I'd suggest reiterating here the requirement to verify "client_id"
>      consistency between Request Object and request parameters.
> 
>    OK. 
>     
> 
>      Section 10
> 
>      I'd consider reiterating the security importance (i.e., what breaks if
>      you don't apply the check) of a few key compliance requirements and
>      which entity is responsible for enforcing them:
> 
>      - the "request" and "request_uri" parameters MUST NOT be included in
>        request objects, from Section 4
> 
>      - The request object has the mime-type
>        "application/oauth.authz.req+jwt", also from Section 4
> 
>      - The client_id in the request object has to match the client_id from
>        the request query parameters, from Section 5
> 
>      - The AS must only use parameters from the request object, even if the
>        client has duplicated them in the query parameters, also from Section
>      5
> 
>    OK. 
>     
> 
>      Section 10.2
> 
>         (e)  When a third party, such as a Trust Framework Provider(TFP),
>              provides an endpoint that provides a Request Object URI in
>              exchange for a Request Object.  The same requirements as (b) and
>              (c) above apply.  In addition, the Authorization Server MUST
> 
>      The (b) case is "the symmetric key for JWE encryption"; do we mean "(c)
>      and (d)" here?
> 
>    Good point. Let me check with John and get back to you. 
>     
> 
>      Section 10.3
> 
>      I'm not sure whether the key point of this section is "the following
>      endpoints are RECOMMENDED [...] to use this practice" or "an extension
>      specification should be created as a measure to address the risk".  That
>      is, can a deployment unilaterally apply the message-position and
>      intended-interaction-endpoint protections now, or is there need for
>      additional specification work first?
> 
>    It can be covered by operational rules to some extent but I believe having
>    an extension spec would make things more explicit and less error-prone. 

Okay.  (I can't argue with that conclusion!)

> 
>      Section 10.4
> 
>      I'm not sure how much of this is distinct from the Request URI Rewrite
>      discussed in Section 10.4.2, but having the request object contents be
>      in a separately dereferenceable URI introduces risk of the dereferenced
>      Request Object being dissociated from the triggering request.  (This
>      could happen due to internal error on the client or service hosting the
>      requested URI or content skew over time, in addition to a request URI
>      rewrite.)  Having an externally provided single-use nonce in the reqest
>      object would provide a mitigation, but it also (if I understand
>      correctly) not compatible with all of the envisioned use cases for JAR.
> 
>    Hmm. Current implementations since it is out of OIDC has nonce, I
>    believe. 
>    I need to think a bit about this. 

Okay.  (Thanks for the reminder that OIDC has the nonce; I had forgotten
that.)

> 
>      Section 10.5
> 
>      Should the rejection of "alg":"none" be limited to the
>      require_signed_request_object case, or universally applied?
> 
>    I believe it is for the case require_signed_request_object is true. 
>     
> 
>      Section 12.1
> 
>         (2)  (Translation Process) The client uses the client credential that
>              it got to push the request object to the TFP to get the
>              "request_uri".
> 
>      If I understand correctly, the TFP also verifies that the request object
>      is consistent with the claims the client is eligible for based on the
>      certification step in (1).
> 
>    Yes. 
>    Perhaps I should add text for that. 

I think that would be useful, thanks.

> 
>      Section 12.2.2
> 
>         Therefore, per-user Request Object URI should be avoided.
> 
>      If I understand correctly, the only possible alternative is to have
>      per-request URIs (right?), as coalescing multiple user's requests into a
>      single request object URI seems to pose several difficulties.  We could
>      perhaps make the recommended alternative more clear.
> 
>    Right. I will try to come up with a text for this. 

Maybe just "should be avoided, in favor of per-request URIs"?  Perhaps that
is too strong of a statement, though.

Thanks again for all the updates, and my apologies that progress on this
document has been so spread out in time.

-Ben