[OAUTH-WG] Re: I-D Action: draft-ietf-oauth-attestation-based-client-auth-03.txt

[Benjamin Kaduk]

On Fri, May 31, 2024 at 02:38:29AM -0700, internet-dra...@ietf.org wrote:
> Internet-Draft draft-ietf-oauth-attestation-based-client-auth-03.txt is now
> available. It is a work item of the Web Authorization Protocol (OAUTH) WG of
> the IETF.
> 
>Title:   OAuth 2.0 Attestation-Based Client Authentication
>Authors: Tobias Looker
> Paul Bastian
>Name:draft-ietf-oauth-attestation-based-client-auth-03.txt
>Pages:   16
>Dates:   2024-05-31
> 
> Abstract:
> 
>This specification defines an extension to the OAuth 2 protocol as
>defined in [RFC6749] which enables a Client Instance to include a
>key-bound attestation in interactions with an Authorization Server or
>a Resource Server.  This new method enables Client Instances involved
>in a client deployment that is traditionally viewed as a public
>client, to be able to utilize this key-bound attestation to
>authenticate.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/

Just reading the draft for the first time (so, not a comment on the diff),
it seems like the privacy considerations section should discuss what
exposure there is from the client instance to the client backend.  If I'm
reading correctly, the client attestation JWT is just authorizing the PoP
key that's used in the client attestation PoP JWT, and does not include any
audience or other information that would be specific to the resource at
which the client instance wishes to present the JWT.  So that would make
the client backend only able to see what level of activity the client
instance has but not where exactly that activity is going to.  And if the
attestation JWT is valid for a long time, even that would mask a lot of
potential activity.

Which in turn makes me wonder if we want to give some guidance on how long
of a lifetime both JWTs could/should have.  Even if we don't want to give
specific advice for a good lifetime, we could still analyze the tradeoffs
in doing a longer vs shorter lifetime.

-Ben

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

Re: [OAUTH-WG] client_id in CWT Claims

[Benjamin Kaduk]

I did not do a full in-depth research on this topic, but it looks like my
AD review of what became RFC 9200
(https://mailarchive.ietf.org/arch/msg/ace/k5RzWwmuawvczrHN88JoE3vbH78/)
noted that what-became-RFC8693 had already gotten "scope" registered in the
JWT claims registry, so that RFC 9200 could not attempt to register it in
that registry as well.  I suspect that a botched edit caused that reference
to be used in the CWT claims registry as well, in which case an erratum
should be filed against 9200 -- if verified, that should be enough for IANA
to change the entry in the live registry.

-Ben

On Sun, Jan 28, 2024 at 05:13:07PM -0700, Brian Campbell wrote:
> It took a bit of looking but Neil is correct and that some other document
> is RFC9200:
> 
> https://datatracker.ietf.org/doc/html/rfc9200#name-cbor-web-token-claims
> (last one in that section)
> 
> which doesn't seem quite right. I would have expected the entry in the
> registry to point back to RFC9200, especially because it has details about
> the CWT scope claim (e.g., claim key value and additional binary encoding
> value) that are definitely not in RFC8693.  But that seems to explain the
> state of that entry in the registry anyway.
> 
> On Wed, Jan 24, 2024 at 11:45 AM Neil Madden 
> wrote:
> 
> > RFC8693 didn't register anything for CWT at all. Some other document has
> > registered scope for CWT and pointed at that RFC as the reference for some
> > reason.
> >
> > -- Neil
> >
> > On 24 Jan 2024, at 18:37, Orie Steele  wrote:
> >
> > I'm working on a document that has some similarity to EAT from RATS, in
> > that it is trying to enable JWT and CWT to be used for a use case.
> >
> > Is there a reason that RFC8693 registers "scope" and "client_id" for JWT,
> > but only "scope" for CWT ?
> >
> > - https://www.iana.org/assignments/jwt/jwt.xhtml
> > - https://www.iana.org/assignments/cwt/cwt.xhtml
> >
> > How can I use "client_id" in CWT ?
> >
> > OS
> >
> > --
> >
> > ORIE STEELE
> > Chief Technology Officer
> > www.transmute.industries
> > 
> > ___
> > 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
> >
> 
> -- 
> _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

Re: [OAUTH-WG] [COSE] .well-known/jwks.json and constrained-voucher and RFC7517

[Benjamin Kaduk]

On Tue, Jul 12, 2022 at 09:46:01PM +0200, Warren Parad wrote:
> I don't know if this is relevant, but jwks.json isn't registered, because
> it doesn't have to be at that location. The
> /.well-known/openid-configuration discovery document, which is registered,
> uses the jwks_uri property to specify the location of the jwks. For
> instance, our product doesn't have the jwks at /.well-known/jwks.json for a
> lot of different reasons. Having a discovery document that points to your
> jwks makes sense, ideally you would be able to use the known discovery
> document at /openid-configuration, but I don't know if that is viable or
> makes sense for your context.

Hmm, perhaps we need to give stronger guidance to site operators that the
contents of /.well-known/* belong to "the protocol" and that they pick
arbitrary new (unregistered) names their at their own risk.  (If "you" are
serving content at /.well-known/jwks.json and I go register that URI with
different semantics, clients that know about my new and try it against
"your" server will encounter unexpected behavior.)

(I assume that you, Warren, don't control the baeldung.com pages.)

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] DPoP JWT claims

[Benjamin Kaduk]

On Thu, Jun 16, 2022 at 04:18:49PM -0600, Brian Campbell wrote:
> I'm not sure the JWT claims registry has turned out to be exactly what was
> envisioned. And, to your point, the utility of some of the registrations is
> questionable. The issue of name conflicts vs reuse is more subtle than it

> seems. And practically speaking the registry is kind of the only way to
> legitimately get/use a short claim name (so called private claim names
> aren't ideal and arguably not appropriate for a prospective spec).

This is probably the main reason I'm still in favor of registering short
claim names -- people are going to want to use them and it's better to have
most things in the registry than to have completely independent siloed
usage.

> There was some sort of related discussion with an AD a while back
> https://mailarchive.ietf.org/arch/msg/jwt-reg-review/O4rmJbMOZZFbi6mlVk6VHp-xUs8/
> that basically resulted in "just go ahead and register stuff". At least
> that was my takeaway.

I think we both (at the time) thought that it's better to have (registered)
claim names that reflect the specificity of expected usage.  We can't
always have nice things, though (case in point: all the existing
registrations), and we're not going to "keep the registry pure" in whatever
sense by pushing back hard on new registrations.  So that's how we end up
in practice with "go ahead and register stuff", though we can certainly ask
people if they want a more-specific name.

> FWIW there was also some discussion around those very questions with
> respect to "nonce" (see
> https://github.com/danielfett/draft-dpop/pull/81#discussion_r713354503 and
> maybe a few comments back) with some push-back on using it. But the outcome
> was to go ahead with nonce but also update the registry via a OIDC errata.
> Though I suspect that action got lost in the shuffle. Maybe DPoP should do
> it?

I do have some general unease about reusing the claim (name) for a
different meaning/usage without updating the registry in some manner.
Consult a current AD for an authoritative reference, but I expect that OIDC
has some form of "change control" over the existing registration and would
need to be involved in some form if this change is made.

As another data point, over in draft-ietf-ace-oauth-authz I made people
create a new "cnonce" claim instead of reusing the existing "nonce" (also
as claimed by OIDC).

-Ben

> On Thu, Jun 16, 2022 at 3:33 PM Neil Madden 
> wrote:
> 
> > Is that actually true? The DPoP spec itself is a case in point: it reuses
> > the existing OIDC “nonce” claim but explicitly says that DPoP nonces are
> > not like OIDC nonces (section 9):
> >
> > “ Developers should also take care to not
> >
> >confuse DPoP nonces with the OpenID Connect [OpenID.Core 
> > ]
> >  ID Token
> >nonce.”
> >
> >
> > The official IANA registration of “nonce” says:
> >
> >
> > Value used to associate a Client session with an ID Token
> >
> >
> > Does this matter? If not, does it matter if some other spec defines a “htm” 
> > claim with different meaning?
> >
> >
> > On 16 Jun 2022, at 20:50, Dick Hardt  wrote:
> >
> > 
> > Registering the names provides clarity on use and avoids confusion on the
> > meaning of a claim — ie two specs won’t have conflicting definitions of
> > “htm”
> >
> > On Thu, Jun 16, 2022 at 10:20 AM Warren Parad  > 40rhosys...@dmarc.ietf.org> wrote:
> >
> >> I think the registration really helps with discovery, especially as an
> >> implementer. When you see or observe these claims in a JWT, you can google
> >> them potentially returning no results. If you know about the IANA registry
> >> you can find them, even if you don't know that the tokens have anything to
> >> do with DPoP.
> >>
> >> On Thu, Jun 16, 2022 at 6:21 PM Neil Madden 
> >> wrote:
> >>
> >>> The DPoP spec registers the “htm”, “htu”, and “ath” claims [1]. But do
> >>> these claims actually make sense outside of a DPoP proof? Presumably the
> >>> risk of naming collision within a DPoP proof is pretty small, so is there
> >>> any benefit to registering them rather than just using them as private
> >>> claims?
> >>>
> >>> (I guess I could ask the same question about lots of other entries in
> >>> the current registry at IANA, many of which look completely app-specific 
> >>> to
> >>> me).
> >>>
> >>> [1]:
> >>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop#section-12.7
> >>>
> >>>
> >>> — Neil
> >>> ___
> >>> 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
> >
> 
> -- 
> _CONFIDENTIALITY NOTICE: This 

Re: [OAUTH-WG] Proposed changes to RFC 8705 (oauth-mtls)

[Benjamin Kaduk]

On Thu, Dec 09, 2021 at 09:59:58PM +0100, Warren Parad wrote:
> 
> If we want to signal that the token should be used with mTLS and not
> without, that to me says "claim" as "*mtls: true"*. Further, Bearer says
> "use this as is, it doesn't need to be modified", the token doesn't need to
> be modified to use it with mTLS so Bearer is correct.

I can see how you might read Section 7.1 of RFC 6749 as saying that
"bearer" refers soley to "simply including the access token string in the
request".  But if you go follow the reference to RFC 6750, it's right there
in the abstract that:

   [...] Any party in
   possession of a bearer token (a "bearer") can use it to get access to
   the associated resources (without demonstrating possession of a
   cryptographic key).

I.e., if a token requires proof of possession of a cryptographic key in
order to use the token, it's not a bearer token.
So I really don't see any evidence to support a claim that the original
intent was for Bearer to be used even for PoP tokens.
That said...

> I really wish we would stop trying to create different token values for the
> part of the Authorization header string that comes before the token. Having
> DPoP token type is bothering me as well, do we need it there, probably not,
> but that's not this discussion. At this point we should consider the
> *token_type* functionality fundamentally broken, and realistically a
> vestigial piece of OAuth that neither offers value nor should be reasonably
> used for any purpose. If so desired, then let's put the mTLS signaling flag
> as a claim where anyone and everyone can see it without having to magically
> know what protocol was used to convey the HTTP message to the RS.

... this part may still be true, in practice, given the current deployed
reality.

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-iss-auth-resp-03: (with COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-iss-auth-resp-03: Yes

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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/



--
COMMENT:
--

Is the authorization endpoint the only one that would benefit from the
added "iss" protection?  Should we say anything about the utility of the
"iss" parameter in other responses?

Section 2

  If the authorization
   server provides metadata as defined in [RFC8414], the value of the
   parameter iss MUST be identical to the authorization server metadata
   value issuer.

Does it ever make sense to implement this document but not provide
metadata as in RFC 8414?  Should this document give any guidance (e.g.,
SHOULD or MUST) about also implementing RFC 8414 if this document is
implemented?

Section 2.1

Thank you for using a nice random code with 256 bits of entropy in the
example :)

Section 2.2

Should we use a different 'state' value for the example successful
response and example error response?

Section 2.3

   *  The issuer identifier included in the server's metadata value
  issuer MUST be identical to the iss parameter's value.

I think we attempted to impose this requirement using the BCP 14 MUST
keyword up in toplevel section 2 as well.  Generally my advice is to
only use the normative keywords in one place for any given requirement,
to avoid any risk of conflicting guidance that could lead to different
implementation behaviors.  (In this case, putting the MUST here seems to
make more sense, since it's an explicit listing of "the following rules
apply".)

NITS

Section 2.4

   If clients interact with both authorization servers supporting this
   specification and authorization servers not supporting this
   specification, clients MUST store the information which authorization
   server supports the iss parameter.  Clients MUST reject authorization

I think there's a missing word here, for "the information about" or even
a broader rewording to "MUST retain state about whether each
authorization server supports the iss parameter".

   support in their metadata.  Local policy or configuration can
   determine whether to accept such responses and specific guidance is
   out of scope for this specification.

I'd suggest s/whether/when/, since we already do give default guidance
("SHOULD discard") earlier.



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] How to report a possible security threat

[Benjamin Kaduk]

On Sat, Aug 28, 2021 at 03:56:51PM +0200, Rutger Hertogh wrote:
> Hi all,
> 
> How can I report a possible security threat?

The answer depends on whether it's believed to be an issue with the
protocol itself vs a specific implementation or implementations of it.

The IETF guidance on reporting protocol vunlerabilities (the former
category) is available at
https://www.ietf.org/standards/rfcs/vulnerabilities/

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [mglt.i...@gmail.com: Re: [Ace] Missing Introspection parameter in draft-ietf-ace-oauth-authz]

[Benjamin Kaduk]

Hi OAuth-ers,

Just a heads-up that ACE is doing a quick WGLC to confirm that we should
register a new "cti" introspection parameter in our core spec, to match up
with the CWT token identifier claim of that name.  The document is already
in the RFC Editor's queue, so I wanted to raise visibility of this
"last-minute" change.

Please send any comments to a...@ietf.org or me directly.

Thanks,

Ben

- Forwarded message from Daniel Migault  -

Date: Tue, 17 Aug 2021 11:25:10 -0400
From: Daniel Migault 
To: Ludwig Seitz 
Cc: "a...@ietf.org" 
Subject: Re: [Ace] Missing Introspection parameter in draft-ietf-ace-oauth-authz

Thanks Ludwig for raising the question. If anyone has an objection, please
express your concern by August 24. Expressing support is also more than
welcome!

Yours,
Daniel

On Tue, Aug 17, 2021 at 10:24 AM Ludwig Seitz 
wrote:

> Hello ACE,
>
> I want to raise one issue for group comments that has come up in
> conjunction with fixing the IANA nits for draft-ietf-ace-oauth-authz:
> In figure 16 we define mappings from OAuth Token introspection parameters
> to CBOR abbreviations. These parameters (should) correspond to the claims
> that could be found in e.g., a CWT.
> CWT renamed one token claim, namely 'jti' (JWT ID) into 'cti' for CWT ID.
> However, this is not reflected in the registered Introspection parameters
> (
> https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-introspection-response)
> where only 'jti' is registered. This was overlooked when we originally
> defined the mappings in figure 16.
>
> I would therefore put the following question to the group:
>
> Does anyone object to this draft adding 'cti' as an OAuth introspection
> parameter?
>
> The corresponding text would go into the list of additional parameters in
> section 5.9.2 and be something along the lines of:
> "cti  OPTIONAL.  The CWT ID parameter has the same meaning and processing
> rules as the "jti" parameter defined in section 3.1.2. of [RFC 7662] except
> that the value is a byte string. "
>
> Regards,
>
> Ludwig
>
> --
> Ludwig Seitz
> Infrastructure Security Analyst
> Combitech AB
> Djäknegatan 31 . SE-211 35 Malmö . Sweden
> Phone: +46 102 160 846
> ludwig.se...@combitech.com . combitech.com This e-mail is private and
> confidential between the sender and the addressee. In the event of
> misdirection, the recipient is prohibited from using, copying or
> disseminating it or any information in it. Please notify the above of any
> such misdirection Please consider the environment before printing this
> e-mail!
>
>
> ___
> Ace mailing list
> a...@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>


-- 
Daniel Migault
Ericsson

___
Ace mailing list
a...@ietf.org
https://www.ietf.org/mailman/listinfo/ace


- End forwarded message -

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [DPoP] Protected resource access and invalid DPoP proofs

[Benjamin Kaduk]

On Thu, Aug 12, 2021 at 05:05:03PM -0600, Brian Campbell wrote:
> Indeed but this case would be only distinguishing between which of the two
> things (token & proof) the client sent was invalid. It seems like a
> reasonable amount of information to disclose that might be helpful in
> troubleshooting while not giving actionable info to would-be attackers.

Agreed on what information is conveyed here.
My thinking may be shaped from work on 2FA for Kerberos, where we go to
great lengths to not reveal whether the password or second-factor code was
incorrect, to avoid a "divide-and-conquer" type attack on human-selected
passwords.  The situation is, admittedly, different here.

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [DPoP] Protected resource access and invalid DPoP proofs

[Benjamin Kaduk]

It's not immediately obvious to me that making the distinction is good (but
I'm also basically devoid of the context in which this exchange will
occur).

With security protocols there can be risks from overly descriptive errors,
which might (e.g.) leak information that "this is a valid token" vs "this
is a bogus token" that an attacker who came upon something token-shaped
might not otherwise be able to ascertain.

-Ben

On Mon, Aug 09, 2021 at 03:58:22PM -0600, Brian Campbell wrote:
> Hi Dmitry,
> 
> I think you are right that it's probably worthwhile to allow for a
> distinction in a protected resource error response. I'm inclined to say
> that a new error code such as "invalid_dpop_proof" to use with the 401
> response containing the DPoP WWW-Authenticate header is the most
> straightforward way to accommodate it in the document. I'll look to add
> that, probably somewhere in section 7
> ,
> in the next draft revision.
> 
> 
> On Thu, Aug 5, 2021 at 8:50 AM Dmitry Telegin  40backbase@dmarc.ietf.org> wrote:
> 
> > Hello,
> >
> > When a protected resource is accessed using DPoP proof + DPoP-bound access
> > token, either of those could be invalid. Should we make distinction between
> > these two cases? I.e. should the response always be a 401 Unauthorized with
> > WWW-Authenticate: DPoP ... error="invalid_token"? or could we use
> > error="invalid_dpop_proof", similar to token request? or maybe even 400 Bad
> > Request?
> >
> > Regards,
> > Dmitry
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> 
> -- 
> _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

Re: [OAUTH-WG] [DPoP] Protected resource access and invalid DPoP proofs

[Benjamin Kaduk]

On Thu, Aug 12, 2021 at 02:17:24PM -0600, Brian Campbell wrote:
> It might be worth a mention but I'm always a little hesitant about
> potentially repeating content from other specs (and maybe even getting it
> wrong!). Maybe a very brief mention along with a pointer to that section in
> RFC 7235 would be appropriate? I'm curious what other WG folk think about
> this though?

Brief mention + reference seems good to me.

> FWIW, https://datatracker.ietf.org/doc/html/rfc7235#section-4.1 does say
> "the [WWW-Authenticate] header field itself can occur multiple times."

Yes, both this and the implication to offer both challenges should be
unsurprising to people fully steeped in the workings of HTTP (which one
assumes does not cover anywhere close to all people that will be looking at
DPoP).

-Ben

P.S. If you want to become a person steeped in the workings of HTTP,
https://datatracker.ietf.org/doc/draft-ietf-httpbis-semantics/ is a pretty
good place to start.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-par-08: (with COMMENT)

[Benjamin Kaduk]

Hi Brian,

On Wed, Jun 30, 2021 at 01:10:37PM -0600, Brian Campbell wrote:
> Thanks Ben, I've endeavored to respond to your comments inline below. And I
> will/am working on related document updates but have some time off planned
> around the 4th of July so likely won't have a new revision out until next
> week sometime.

Understandable!

> On Mon, Jun 28, 2021 at 1:45 PM Benjamin Kaduk via Datatracker <
> nore...@ietf.org> wrote:
> 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-oauth-par-08: Yes
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-par/
> >
> >
> > --
> > COMMENT:
> > --
> >
> > I made a github PR with some editorial suggestions, at
> > https://github.com/oauthstuff/draft-oauth-par/pull/70 .
> >
> 
> Merged on Monday. Thank you.
> 
> 
> Section 1
> >
> >Those apps typically invoke a
> >custom tab with an URL that is translated into a GET request.  Using
> >"POST" would require the app to first open a web page under its
> >control in the custom tab that in turn would initiate the form "POST"
> >towards the authorization server.  PAR is simpler to use and has
> >additional security benefits as described above.
> >
> > This description leaves me with a feeling that I only have an incomplete
> > picture of why POST is "prohibitively difficult" to use with mobile
> > apps.  It seems like the setup is describing a scenario where the
> > authorization logic is operating inside a framework or environment
> > provided by some other entity that is unwilling or unable to change the
> > framework to accomodate new OAuth behavior.  Is this other entity the
> > author of the mobile app, or an app framework, or somethint else?
> > Having a bit more description of the multiple entities involved and
> > which one is trying to control the specific mechanics of the
> > authorization request would make this depiction a more compelling
> > argument that POST is unusable.
> >
> 
> I think perhaps myself and co-authors are so familiar with it that it seems
> almost self-evident. This is the second ballot comment on this paragraph,
> however, so it seems some more work on the text is warranted. I'll try to
> elaborate and better explain why it isn't particularly viable for a native
> mobile app to cause the user's browser on the device to make a POST request
> (with sizable body content).

I think that even mentioning that there are ecosystem pressures to use the
native (OS?) browser for an otherwise independent app (that acts as OAuth
client) would be helpful.  The fact that the interface between native apps
and the system browser has limitations should be fairly easy to accept as a
fact of life, whereas the current text invites the reader to ask "but can't
you just make a POST request yourself?  Why is that so hard?".

> 
> 
> 
> > Section 1.1
> >
> >  POST /as/par HTTP/1.1
> >  Host: as.example.com
> >  Content-Type: application/x-www-form-urlencoded
> >  Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
> >
> > My personal preference would be to have examples that just want a
> > generic HTTP authentication mechanism to use something stronger than
> > Basic, though I don't think this is something that I can insist on, at
> > present.  (Applies throughout.)
> >
> 
> I wavered on this very point when putting together the examples but
> eventually took the easy route and went with Basic (aka
> client_secret_basic). The three such examples just want to show some form
> of OAuth client authentication happening. I think JWT based client
> assertion authentication using asymmetric keys
> https://datatracker.ietf.org/doc/html/rfc7523#section-2.2 (aka
> private_key_jwt) is the only stronger mechanism that would show well in
> examples (MTLS/RFC8705 is hard to show in a meaningful way in an HTTP
> example). I could update the examples to use RFC7523
> client_assertion/client_assertion_type parameter auth?

That would address my concern, but I understand that it's a nontrivial
amount of work and definitely am not insisting on it.

> 
> 
> 
> >  HTTP/1.1 201 Created
> >  Cache-Control: no-cache, no-store
> >  Content-Type: application/json
> >
> >  {
> >"request_uri": "urn:example:bwc4JK-ES

[OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-par-08: (with COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-par-08: Yes

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 DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-par/



--
COMMENT:
--

I made a github PR with some editorial suggestions, at
https://github.com/oauthstuff/draft-oauth-par/pull/70 .

Section 1

   Those apps typically invoke a
   custom tab with an URL that is translated into a GET request.  Using
   "POST" would require the app to first open a web page under its
   control in the custom tab that in turn would initiate the form "POST"
   towards the authorization server.  PAR is simpler to use and has
   additional security benefits as described above.

This description leaves me with a feeling that I only have an incomplete
picture of why POST is "prohibitively difficult" to use with mobile
apps.  It seems like the setup is describing a scenario where the
authorization logic is operating inside a framework or environment
provided by some other entity that is unwilling or unable to change the
framework to accomodate new OAuth behavior.  Is this other entity the
author of the mobile app, or an app framework, or somethint else?
Having a bit more description of the multiple entities involved and
which one is trying to control the specific mechanics of the
authorization request would make this depiction a more compelling
argument that POST is unusable.

Section 1.1

 POST /as/par HTTP/1.1
 Host: as.example.com
 Content-Type: application/x-www-form-urlencoded
 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

My personal preference would be to have examples that just want a
generic HTTP authentication mechanism to use something stronger than
Basic, though I don't think this is something that I can insist on, at
present.  (Applies throughout.)

 HTTP/1.1 201 Created
 Cache-Control: no-cache, no-store
 Content-Type: application/json

 {
   "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2",
   "expires_in": 90
 }

The "request_uri" element's semantics feels like a very natural fit for
the native HTTP "Location" response header field (vs requiring a
specific element in the JSON body of the response).  I am less sure that
there's a native HTTP element for the expiration time, as the HTTP
timeouts tend to be associated with HTTP caching vs the actual lifetime
of the resource.

Section 2

It feels a little unfortunate that we have to reuse the metadata
parameters relating to the token_endpoint_auth_method for PAR, but
creating new metadata parameters that are basically always going to hold
the same values is probably worse...

Section 2.1

Any token endpoint parameters that are not related
   to client authentication have no defined meaning for a pushed
   authorization request.  [...]

I suppose that in most cases, whether or not a token endpoint parameter
is related to client authentication should be fairly unambiguous ... but
the registry at
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters
has a dedicated column for "parameter usage location".  It seems like it
would be fairly straightforward to add "pushed authorization request" as
an additional possible value there and remove the ambiguity.  We could
enumerate the existing parameters that are applicable and update the
references for the registry to include this document.

Section 2.1

   The authorization server MUST process the request as follows:

We often see descriptions along the lines of "this is not intended to
constrain implementation techniques; any procedure that results in an
equivalent outcome is permissible".  This procedure is simple enough
that we may not need to have concerns of that nature, though.

Section 2.2

   *  "request_uri" : The request URI corresponding to the authorization
  request posted.  This URI is used as reference to the respective
  request data in the subsequent authorization request only.  [...]

Would it be appropriate to use the phrase "single-use" in this
description?

Section 2.4

   It is at the discretion of the authorization server to apply
   restrictions on supplied "redirect_uri" values, e.g. the
   authorization server MAY require a certain URI prefix or allow only a
   query parameter t

[OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwt-introspection-response-11: (with COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-jwt-introspection-response-11: 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 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/



--
COMMENT:
--

Thank you for addressing my Discuss (and Comment) points!

Just a couple final notes on the -11:

Section 4

Please double-check that describing the resource server as
"authenticating with a private-key JWT" is compatible with using the
urn:ietf;params:oauth:client-assertion-type:jwt-bearer assertion type.
I am not up-to-date on the precise semantics of that assertion type, offhand.

Section 5

   Token introspection response parameter names intended to be
   used across domains SHOULD be registered in the OAuth Token
   Introspection Response registry
   [IANA.OAuth.Token.Introspection] defined by [RFC7662].

I'm a bit surprised to see any normative terminology used on the
question of whether response parameter names are to be registered, since
RFC 7662 already has a requirement ("MUST") for this scenario.  If the
intent truly is to weaken the requirement from RFC 7662, it seems that
some additional clarification is in order that this is a change from the
existing specification and why it is a desirable change.
(The "MAY extend the token introspection response" in the preceding
paragraph, not quoted, is also already present in RFC 7662.)



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Editorial Errata Reported] RFC7591 (6619)

[Benjamin Kaduk]

On Wed, Jun 23, 2021 at 12:04:47AM +, Dave Isaacs wrote:
> Fair enough, I guess. The HTML versions of the older RFCs must be peppered 
> with bad links if this is the case.

Yes, that is true, and we get some periodic errata reports of this nature
as well.

I marked this report as rejected per the policy that John described.

> It is interesting to note that there is a correct link to RFC 6749 in the 
> paragraph immediately before the one I quoted. Given what you have said, I am 
> going to take a wild guess that replacing “OAuth 2.0, Section 2.1” with 
> “Section 2.1 of OAuth 2.0 [RFC6749]” would fix the issue.

IIRC it would have to be "Section 2.1 of [RFC6749]" (with no title of the
referenced RFC).

-Ben

> 
> Dave I
> 
> 
> From: John R. Levine 
> Date: Tuesday, June 22, 2021 at 7:03 PM
> To: RFC Errata System , i...@justin.richer.org 
> , m...@microsoft.com , 
> ve7...@ve7jtb.com , maciej.machu...@gmail.com 
> , phil.h...@yahoo.com , 
> r...@cert.org , ka...@mit.edu , 
> hannes.tschofe...@gmx.net , 
> rifaat.s.i...@gmail.com 
> Cc: Dave Isaacs , oauth@ietf.org 
> Subject: Re: [Editorial Errata Reported] RFC7591 (6619)
> Htmlized legacy RFCs are created by a script that uses heuristics to add
> formatting to the canonical text document.  One of the limitations of the
> script is that it does not know when a section link is to another
> document.
> 
> For RFCs published since we switched to XML v3 two years ago, the HTML is
> created directly from the XML and the links are correct.
> 
> Since the underlying RFC is correct and currrent RFCs don't have the
> problem we're not planning to try to fix it.
> 
> Regards,
> John Levine, temporary RFC series manager
> 
> On Tue, 22 Jun 2021, RFC Errata System wrote:
> 
> > The following errata report has been submitted for RFC7591,
> > "OAuth 2.0 Dynamic Client Registration Protocol".
> >
> > --
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid6619
> >
> > --
> > Type: Editorial
> > Reported by: Dave Isaacs 
> >
> > Section: 2
> >
> > Original Text
> > -
> > token_endpoint_auth_method
> >  String indicator of the requested authentication method for the
> >  token endpoint.  Values defined by this specification are:
> >
> >  *  "none": The client is a public client as defined in OAuth 2.0,
> > Section 2.1, and does not have a client secret.
> >
> >  *  "client_secret_post": The client uses the HTTP POST parameters
> > as defined in OAuth 2.0, Section 2.3.1.
> >
> >  *  "client_secret_basic": The client uses HTTP Basic as defined in
> > OAuth 2.0, Section 2.3.1.
> >
> > Corrected Text
> > --
> > Text unchanged. It is the links that are incorrect.
> >
> > Notes
> > -
> > The links that are present in each bullet—to Section 2.1, and to Section 
> > 2.3.1 (twice)—link internally to the current RFC (RFC 7591) when they are 
> > supposed to link to the OAuth 2.0 RFC (RFC 6749).
> >
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --
> > RFC7591 (draft-ietf-oauth-dyn-reg-30)
> > --
> > Title   : OAuth 2.0 Dynamic Client Registration Protocol
> > Publication Date: July 2015
> > Author(s)   : J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, P. 
> > Hunt
> > Category: PROPOSED STANDARD
> > Source  : Web Authorization Protocol
> > Area: Security
> > Stream  : IETF
> > Verifying Party : IESG
> >
> >
> 
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for 
> Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly
> Have you heard? SurveyMonkey (SVMK Inc.) is now Momentive. Learn more at 
> momentive.ai

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (6613)

[Benjamin Kaduk]

This looks correct to me; could the authors/WG please confirm?

Thanks,

Ben

On Thu, Jun 17, 2021 at 12:04:37PM -0700, RFC Errata System wrote:
> The following errata report has been submitted for RFC6749,
> "The OAuth 2.0 Authorization Framework".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6613
> 
> --
> Type: Editorial
> Reported by: Daniel Barclay 
> 
> Section: 3.3
> 
> Original Text
> -
> The value of the scope parameter is expressed as a list of space-delimited, 
> case-sensitive strings
> 
> Corrected Text
> --
> The value of the scope parameter is expressed as a space-delimited list of 
> case-sensitive strings
> 
> Notes
> -
> The original/current seems to be a bit confusing.
> 
> The value is not a collection of space-delimited strings (whatever a 
> "space-delimited string" would be), but it a space-delimited (representation 
> of) a collection of strings.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC6749 (draft-ietf-oauth-v2-31)
> --
> Title   : The OAuth 2.0 Authorization Framework
> Publication Date: October 2012
> Author(s)   : D. Hardt, Ed.
> Category: PROPOSED STANDARD
> Source  : Web Authorization Protocol
> Area: Security
> Stream  : IETF
> Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Benjamin Kaduk]

Hi Mike,

Also inline...

On Thu, Apr 08, 2021 at 04:45:15AM +, Mike Jones wrote:
> Thanks for your review, Ben.  We've published 
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-33 to address your and 
> other IESG comments.
> 
> Responses are inline below, prefixed by "Mike>".
> 
> -Original Message-
> From: OAuth  On Behalf Of Benjamin Kaduk via 
> Datatracker
> Sent: Tuesday, April 6, 2021 11:39 AM
> To: The IESG 
> Cc: oauth@ietf.org; oauth-cha...@ietf.org; draft-ietf-oauth-jws...@ietf.org
> Subject: Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-32: (with 
> COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-oauth-jwsreq-32: 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:
> --
> 
> Thank you for the new security considerations text in Sections 10.7 and
> 10.8 since I last reviewed; it does a great job capturing my comments (and 
> the current deployed reality).
> 
> Thanks also to Watson Ladd for the latest secdir review and the authors for 
> their responses to it.
> 
> Mike> Glad to hear it!
> 
> Section 6.2
> 
>The Authorization Server MUST validate the signature of the JSON Web
>Signature [RFC7515] signed Request Object.  The signature MUST be
>validated using a key associated with the client and the algorithm
>specified in the "alg" Header Parameter.  [...]
> 
> The last version I reviewed had some language tying the algorithm used for 
> verification back to a registration (and I commented that perhaps a 
> registration might not always exist).  This language seems to set the 
> recipient up to blindly use the "alg" header parameter, even if it's "none", 
> and we should probably have some hedging language here (I see we do have 
> language elsewhere that bans "none" specifically)...
> 
>  If a "kid" Header Parameter
>is present, the key identified MUST be the key used, and MUST be a
>key associated with the client.  Algorithm verification MUST be
>performed, as specified in Sections 3.1 and 3.2 of [RFC8725].
> 
> ... and maybe that would just take the form of swapping the order of these 
> two sentences, now that I keep reading.
> 
> Mike> Order swapped, per your suggestion.
> 
> Section 10.2
> 
> Do any of the procedures listed for steps (c) and/or (d) need to be performed 
> in step (e) as well?  (In particular, the requirements on the returned URI 
> seem like they would still apply, and possibly the need for client 
> authentication.
> 
> Mike> Having re-read (c), (d), and (e), I don't think so.  The returned URI 
> in (e) can be an opaque identifier that is not a URL, so the URL checking 
> logic wouldn't apply.

Okay.  Thanks for taking a second look.

> Section 10.3
> 
> Nat's response at
> https://mailarchive.ietf.org/arch/msg/oauth/hB_ON_BR0fDf3NSDFcFo5MwbZ2Y/ to 
> my previous review suggested that there might be value in future work that 
> specifies the linkage across these endpoints to try to address the 
> cross-phase attacks discussed in [FETT].  However, the paragraph that I had 
> commented on (that mentions "an extension specification") has since been 
> removed, and I failed to track down why just from a quick mailarchive search. 
>  There may well have been a good reason for removing it (and the reference to 
> [FETT]), so please help refresh my memory if that's the case.
> 
> Mike> It was removed as suggested by Watson Ladd in the discussion that 
> resulted from his SecDir review.

Ah!  Thanks for refreshing my memory.

> Section 10.4
> 
>The introduction of "request_uri" introduces several attack
>possibilities.  Consult the security considerations in Section 7 of
>RFC3986 [RFC3986] for more information regarding risks associated
>with URIs.
> 
> My previous comments had mentioned that because of time skew the dereferenced 
> request URI might actually have the contents of a different request than the 
> one intended, and Nat's respon

Re: [OAUTH-WG] oauth-access-token-jwt: comments and clarifications

[Benjamin Kaduk]

Hi Roberto,

On Fri, Apr 02, 2021 at 11:55:27AM +0200, Roberto Polli wrote:
> Hi Vittorio et al,
> 
> some considerations on oauth access token jwt follows.
> You can see them here too
> https://docs.google.com/document/d/1XsvBzGvhcY0N6vJNgLx6G1dJ5trvgwYRJA9F_NCakbU/edit
> 
> An example with client_credential grant type would be nice too.
> 
> My 2¢,
> R.
> 
> § 1.2  Terminology
> 
> + The terms "Collision-Resistant",  is used according to Section 2 of
> {{JWT}}.
> 
> §2.1 Header
> 
> - mentioning "none" alg can be redundant. I'd reference all the JWT BCP
> instead.
> - I'd add an example header, eg
> 
> ~~~ example
> 
> {
> 
>   "typ": "at+jwt",
> 
>   "alg": "PS256"
> 
> }
> 
> ~~~
> 
> 
> § 2.2.1 Authentication Information Claims
> 
> Is it worth mentioning the "implicit flow"?
> 
> §2.2.2 Identity Claims
> 
> - use the "Collision-Resistant" definition in {{JWT}}
> 
> §2.2.3 Authorization Claims
> 
> - " ... scope parameter..."  should `scope` be quoted?
> -  "All the individual scope strings in the "scope" claim MUST have meaning
> for the resources indicated in the "aud" claim."
> ^ otherwise the error returned is ...? Should we reference §4 here?
> 
> §2.2.3.1 Claims for Authorization Outside of Delegation Scenarios
> - which are the delegated scenarios described in RFC7519? Do you refer to
> "When using an administratively delegated
>   namespace" ? It is not clear to a first-reader.
> 
> §3 Requesting a JWT Access Token
> - an example with `client_credential` grant type would be great.
> - iiuc `jti` is required, the example does not report it.

That's a very good catch; thank you!

-Ben

> §4 Validating JWT Access Tokens
> 
> - the step about forbidding "none" is limitative WRT JWT BCP 8725

> ___
> 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

Re: [OAUTH-WG] Martin Duke's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)

[Benjamin Kaduk]

On Thu, Apr 01, 2021 at 01:32:08PM -0700, Martin Duke via Datatracker wrote:
> Martin Duke has entered the following ballot position for
> draft-ietf-oauth-access-token-jwt-12: 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-access-token-jwt/
> 
> 
> 
> --
> COMMENT:
> --
> 
> (2.1) "...can use any signing algorithm." I presume there ought to be some
> qualifiers on allowed algorithms?
> 
> (4) and (5) "This specification
>does not provide a mechanism for identifying a specific key as the
>one used to sign JWT access tokens."
> 
> I don't understand; there's a key ID right there in the token header?

The concern here is about identifying keys authorized to sign JWS access
tokens.  The server-provided metadata that lists such keys has a single
bucket that covers keys used for signing different things, so you don't get
any security benefit from key isolation, and a compromise of any of the
(other) keys listed by the server would allow the attacker to sign JWT
access tokens that are accepted as valid.

So in a sense this is not about which key was actually used, but rather
which key is supposed to be used.

> (4) I presume it's important that any resouree server rejection of the token
> should be constant-time. Is this somewhere in the RFC tree, or do we need to
> explicitly say it here and/or in Security Considerations?

(A good question, but I don't actually have the answer handy in memory.)

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-access-token-jwt-12: 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-access-token-jwt/



--
COMMENT:
--

Section 2.1

   JWT access tokens MUST include this media type in the "typ" header
   parameter to explicitly declare that the JWT represents an access
   token complying with this profile.  Per the definition of "typ" in
   Section 4.1.9 of [RFC7515], it is RECOMMENDED that the "application/"
   prefix be omitted.  [...]

Just to check: is the reason this is only RECOMMENDED just because
that's the requirement level that RFC 7515 used?  AFAIK we can be more
stringent here and just always require it to appear as "at+jwt", to
simplify processing, if that is compatible with existing deployments (or
we are willing to declare them non-conformant).  (Section 4 would change
accordingly if this text changes.)

Section 2.2

Why does "iat" get an extra sentence describing the claim in addition to
"as defined in [reference]" but not iss/exp/jti/etc.?

Section 2.2.1

   response (e.g., via the implicit flow) or after one or more token
   exchanges (e.g., obtaining a fresh access token using a refresh
   token, or exchanging one access token for another via [RFC8693]).

nit: RFC 8693 doesn't effectuate token exchange; the protocol it
specifies does.  So "via the token exchange mechanism of [RFC8693]" or
"via [RFC8693] procedures" or such seems more grammatically correct.

Section 2.2.2

   Any additional identity attribute whose semantic is well described by
   an entry in the JSON Web Token (JWT) IANA registry introduced in
   [RFC7519] SHOULD be encoded using the corresponding claim name.  Note
   that the JWT IANA registry includes the claims found in Section 5.1
   of [OpenID.Core].

I assume that ths "SHOULD be encoded using the corresponding claim name"
just refers to the claim name used, and is not advising that all
identity attributes be always included.  If so, perhaps a few more words
would help clarify, such as "if that attribute is to be included in the
JWT access token" at the end of the sentence.  Semantically it would
also work to start the sentence with "when being included", but IMO that
would detract from the focus of the sentence.

   Authorization servers including resource owner attributes in JWT
   access tokens should exercise care and verify that all privacy
   requirements are met, as discussed in Section 6.

I'd suggest to s/should/need to/.

Section 2.2.3

   All the individual scope strings in the "scope" claim MUST have
   meaning for the resources indicated in the "aud" claim.  See
   Section 5 for more considerations about the relationship between
   scope strings and resources indicated by the "aud" claim.

["aud" vs "resource?]

Section 2.2.3.1

   An authorization server wanting to include such attributes in a JWT
   access token SHOULD use as claim types the "groups","roles" and
   "entitlements" attributes of the "User" resource schema defined by
   Section 4.1.2 of [RFC7643]).

I do see that we go on to clarify that we register JWT claims for
"groups", "roles", and "entitlements" and recommend encoding guidance
for the values of these claims, but I'm still stumbling over the phrase
"claim types" here.  What is a "claim type"?  I suspect from context
that it is meant to refer to a "claim name" as recorded in the JWT
Claims registry, but I'm not 100% certain.  It might also help
readability to split this into two sentences: "use as claims [list].
The semantic contents of these claims are desribed in their definitions
as attributes of [...]", since the current wording has me trying to use
"attributes" in a JWT context, but it's intended to clarify the RFC 7643
reference.

   Authorization servers SHOULD encode the corresponding claim values
   according to the guidance defined in [RFC7643].  In particular, a

Why is this only a "SHOULD"?  We are defining these JWT claims, so we
can nail down exactly what they contain.

   non-normative example of "groups" attribute can be found in
   Section 8.2 of [RFC7643].  No specific vocabulary is provided for
   "roles" and "enti

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

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-jwsreq-32: 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:
--

Thank you for the new security considerations text in Sections 10.7 and
10.8 since I last reviewed; it does a great job capturing my comments
(and the current deployed reality).

Thanks also to Watson Ladd for the latest secdir review and the authors
for their responses to it.

Section 6.2

   The Authorization Server MUST validate the signature of the JSON Web
   Signature [RFC7515] signed Request Object.  The signature MUST be
   validated using a key associated with the client and the algorithm
   specified in the "alg" Header Parameter.  [...]

The last version I reviewed had some language tying the algorithm used
for verification back to a registration (and I commented that perhaps a
registration might not always exist).  This language seems to set the
recipient up to blindly use the "alg" header parameter, even if it's
"none", and we should probably have some hedging language here (I see we
do have language elsewhere that bans "none" specifically)...

 If a "kid" Header Parameter
   is present, the key identified MUST be the key used, and MUST be a
   key associated with the client.  Algorithm verification MUST be
   performed, as specified in Sections 3.1 and 3.2 of [RFC8725].

... and maybe that would just take the form of swapping the order of
these two sentences, now that I keep reading.

Section 10.2

Do any of the procedures listed for steps (c) and/or (d) need to be
performed in step (e) as well?  (In particular, the requirements on the
returned URI seem like they would still apply, and possibly the need for
client authentication.

Section 10.3

Nat's response at
https://mailarchive.ietf.org/arch/msg/oauth/hB_ON_BR0fDf3NSDFcFo5MwbZ2Y/ to my
previous review suggested that there might be value in future work that
specifies the linkage across these endpoints to try to address the
cross-phase attacks discussed in [FETT].  However, the paragraph that I
had commented on (that mentions "an extension specification") has since
been removed, and I failed to track down why just from a quick
mailarchive search.  There may well have been a good reason for removing
it (and the reference to [FETT]), so please help refresh my memory if
that's the case.

Section 10.4

   The introduction of "request_uri" introduces several attack
   possibilities.  Consult the security considerations in Section 7 of
   RFC3986 [RFC3986] for more information regarding risks associated
   with URIs.

My previous comments had mentioned that because of time skew the
dereferenced request URI might actually have the contents of a different
request than the one intended, and Nat's response at
https://mailarchive.ietf.org/arch/msg/oauth/hB_ON_BR0fDf3NSDFcFo5MwbZ2Y/
pointed out that OIDC actually does use a nonce that would prevent such
an occurrence.  Hopefully Nat did get a chance to think about whether
there was anything else that we should mention in this document, on this
topic.  ("There isn't anything else to mention here" is a fine answer; I
just wanted to close the loop on that thread, since I didn't find one in
the mail archive.)

Section 11.1

nit: s/TFP/trusted third-party service/ (multiple instances), since we
stopped using "Trust Framework Provider" in the main body.

Sction 14.1

Not your fault, but BCP 195 now includes both RFC 7525 and RFC 8996 --
thank you for referencing it as BCP 195!  I expect the RFC Editor will
catch the new reference if you don't want to figure out how to notate it
properly.



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Nonce-based Replay Protection for DPoP

[Benjamin Kaduk]

On Tue, Mar 16, 2021 at 05:45:46PM -0400, Rifaat Shekh-Yusef wrote:
> Brian,
> 
> For a nonce-based replay protection you. might want to look at the ACME
> protocol here:
> https://tools.ietf.org/html/rfc8555#section-6.5

Yes, that one is really solid for the sort of thing it does, and I find
myself recommending it over and over again.
Of course, that workflow is not universally applicable, so sometimes it's
not the right thing to do (and I don't remember enough about DPoP to say if
it works there).

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth mTLS and JWK use/key_ops

[Benjamin Kaduk]

On Mon, Mar 08, 2021 at 01:19:46PM +, Neil Madden wrote:
> 
> 
> > On 8 Mar 2021, at 12:50, Neil Madden  wrote:
> > 
> > An interesting question was raised by our developers around the 
> > interpretation of JWK “use” and “key_ops” constraints when publishing a 
> > self-signed certificate for mTLS client authentication. In X.509 the 
> > KeyUsage extension distinguishes between keys intended for use for 
> > verifying general signatures (digitalSignature) and those used for 
> > verifying signatures on certificates (keyCertSign). The JWK spec doesn’t 
> > make this distinction, so there is only the generic “use”:”sig” and 
> > “key_ops”: [“verify”] indicators. So, is “use”:”sig” (or 
> > “key_ops”:[“verify”]) compatible with publishing an X.509 certificate (x5c 
> > claim) that asserts KeyUsage keyCertSign?
> > 
> > It seems plausible that an application might also choose to consume CA 
> > certificates from a central certificate management service that publishes 
> > them in JWK format on an internal HTTPS endpoint. So this question is 
> > potentially broader than just self-signed certs, although that is the only 
> > case discussed in RFC 8705.
> > 
> > In the course of trying to answer this question, I came across 
> > https://github.com/openssl/openssl/issues/1418 
> >  which has links to various 
> > relevant RFCs in the discussion. The conclusion appears to be that when 
> > processing self-signed certificates the KeyUsage check should be skipped. 
> > The reasoning appears to be that we don’t want self-signed certs to assert 
> > the keyCertSign bit, because this increases the risk of them being mistaken 
> > for genuine CA certs. In fact, the language from RFC 5280 suggests this 
> > check should be skipped for any trust anchor, whether self-signed or not.
> 
> I have this part backwards - RFC 5280 path validation skips the KeyUsage 
> check for the end-entity certificate, not the trust anchor cert. This makes 
> more sense. The rest of my comments/questions still apply though.

You do still want to use keyUsage/extendedKeyUsage checks for the
end-entity certificate; it's just that that's part of the application's
verification logic rather than path validation.  (E.g.,
draft-ietf-dtn-tcpclv4-26 provides for a id-kp-bundleSecurity EKU that
gives more authorization than just id-kp-serverAuth.)

My understanding is that JWK was attempting to be much simpler and lighter
weight than PKIX and thus didn't really envision JWKs signing X.509 objects
at all (if I am understanding the questions properly).

Generally, if you are trusting a self-signed certificate, the act of
trusting it would also cover whatever purpose you plan to put it towards,
so any asserted authorizations such as key usage values in the self-signed
certificate object itself are superfluous, so 

We could also pull in the PKIX experts for another opinion, if you want.
Typically we reach out to the LAMPS WG for that (spasm@) at this point.

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-10: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

Hi Vladimir,

Thank you for the link to the proposed updates, and my apologies for having
taken so long to get back to you -- my inbox is in a bit of disarray at the
moment, and I have been (over)relying on the datatracker to tell me what I
need to be doing.

One note from the diff that struck me and I didn't have another place to
comment ont: it seems that we have changed from a "MUST" to a "SHOULD" in
"[t]he authorization server SHOULD be able to determine whether an RS is the
audience for a particular access token and what data it is entitled to
receive".  This does not inherently seem problematic to me; I just
couldn't remember what motivated the change.  So if you could jog my
memory, that would be appreciated.

Further comments inline...

On Tue, Feb 09, 2021 at 11:57:38AM +0200, Vladimir Dzhuvinov wrote:
> Hi Benjamin,
> 
> Thanks a lot for your comments.
> 
> We discussed them and applied several changes to the draft to address them.
> 
> Those changes can be previewed here:
> 
> https://github.com/oauthstuff/draft-ietf-oauth-jwt-introspection-response/compare/address-comments-benjamin-kaduk-2021-01-26
> 
> Further comments inline:
> 
> On 27/01/2021 06:32, Benjamin Kaduk via Datatracker wrote:
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-oauth-jwt-introspection-response-10: 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/
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > We've made a lot of progress at unravelling the gnarly issues relating
> > to merging the introspection response and JWT claims namespaces, which
> > is good.  That said, I'd still like to discuss a little bit more the
> > behavior described in Section 5, where the "token_introspection" claim
> > in the response can also contain JWT claims (''' In addition, claims
> > from the JSON Web Token Claims registry [IANA.JWT] established by
> > [RFC7519] MAY be included as members in the "token_introspection"
> > claim.''')  That seems to be granting carte blanche to do the thing that
> > was deemed problematic, i.e., mix the namespaces.  As such, the current
> > formulation in the document, in the general case of independent
> > uncoordinated implementations, seems to admit the prospect of an AS
> > adding something to an introspection response under the guise of the JWT
> > claim exception that is interpreted by the recipient RS as a new
> > introspection response parameter (or, I think, vice versa).  Yes, this
> > would require conflicting registrations to occur, but we still don't
> > have a procedure in place that would prevent such conflicting
> > registrations from occurring in the future.  How can we add some
> > low-cost safety controls that mitigate the risk while still enabling the
> > desired functionality?
> >
> > I have a couple thoughts on this: there is already an exception for
> > implementation/service-specific (unregistered) claims in the
> > introspection response, which could apply to JWT claims under the same
> > requisite conditions of administrative control, if that's going to cover
> > the scenarios in question.  One could also imagine a new registration
> > procedure for introspection response parameters whereby (for example)
> > any non-conflicting value already registered as a JWT claim can be
> > mechanically propagated into the introspection response registry
> > potentially just by IANA without even expert review.  Then we would just
> > require the contents to be registered introspection response parameters,
> > and someone who wants to use JWT claims can trivially get them
> > registered before using them.
> 
> To recap, the moving of the RFC 7662 response parameters into a
> token_introspection claim was to keep the JWT-specific claims - iss,
> iat, aud (RFC 7519) and the introspection parameters nicely separated
> and thus prevent potential conflicts / confusion between them.
> 
> Speaking of the token introspection parameters, it was identified that
> c

[OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-10: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-jwt-introspection-response-10: 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/



--
DISCUSS:
--

We've made a lot of progress at unravelling the gnarly issues relating
to merging the introspection response and JWT claims namespaces, which
is good.  That said, I'd still like to discuss a little bit more the
behavior described in Section 5, where the "token_introspection" claim
in the response can also contain JWT claims (''' In addition, claims
from the JSON Web Token Claims registry [IANA.JWT] established by
[RFC7519] MAY be included as members in the "token_introspection"
claim.''')  That seems to be granting carte blanche to do the thing that
was deemed problematic, i.e., mix the namespaces.  As such, the current
formulation in the document, in the general case of independent
uncoordinated implementations, seems to admit the prospect of an AS
adding something to an introspection response under the guise of the JWT
claim exception that is interpreted by the recipient RS as a new
introspection response parameter (or, I think, vice versa).  Yes, this
would require conflicting registrations to occur, but we still don't
have a procedure in place that would prevent such conflicting
registrations from occurring in the future.  How can we add some
low-cost safety controls that mitigate the risk while still enabling the
desired functionality?

I have a couple thoughts on this: there is already an exception for
implementation/service-specific (unregistered) claims in the
introspection response, which could apply to JWT claims under the same
requisite conditions of administrative control, if that's going to cover
the scenarios in question.  One could also imagine a new registration
procedure for introspection response parameters whereby (for example)
any non-conflicting value already registered as a JWT claim can be
mechanically propagated into the introspection response registry
potentially just by IANA without even expert review.  Then we would just
require the contents to be registered introspection response parameters,
and someone who wants to use JWT claims can trivially get them
registered before using them.


--
COMMENT:
--

I'm not balloting this at a DISCUSS-level, because it may just be me
failing to understand the intended meaning (or being forgetful), but I'm having 
a hard time
seeing how we're self-consistent about the requirement for an RS to
authenticate and authorize a given RS for a given introspection
transaction.  In particular, in Section 3 we see that "the authorization
server MUST be able to identify, authenticate and authorize resource
servers" and that "[t]he authorization server MUST be able to determine
whether an RS is the audience for a particular access token and what
data it is entitled to receive, otherwise the RS is not authorized to
obtain data for the access token".  While I see that there is also some
discussion about using the "scope" parameter of the token being
introspected as an indicator of the RS it is to be used for (and thus
the identity of the RS that would legitimately be making an
introspection request), and I also see discussion of using an encrypted
introspection response as a way to ensure that the contents are only
viewable by the intended RS, I'm not sure how clearly either (or both)
mechanisms constitute "authentication" of the introspection request.
Since we already require a "strong two-way trust relationship", it's not
clear to me that it would be difficult to strongly authenticate the
actual introspection request itself or that there is much gained by
skipping such a check in favor of other mechanisms.  Several of my
inline comments touch on this topic (on the assumption that there is a
strong MUST for strong authentication); I left them in place to benefit
from the context of where they appear, rather than constructing a
laundry list of all of them.  That said, it will suffice to explain how
I'm wrong/confused just once; there's no need to repeat it at each place
I bring up the topic.

Section 3

   To support encrypted token introspection response JWTs, the
   authorization server MUST also be provided with the respecti

Re: [OAUTH-WG] [Errata Rejected] RFC8176 (6314)

[Benjamin Kaduk]

[adding back rfc-edi...@rfc-editor.org]

Hi David,

I am quite far removed from the actual operation of the script and the
rfc-editor.org website, so I don't know the answer to your question.  That
said, my understanding is that it's set up with automation that assumes the
script is idempotent, and can regenerate various bits from scratch in
certain cases, so a manual edit might not be very reliable.

-Ben

On Tue, Oct 20, 2020 at 09:26:21AM -0700, David Brossard wrote:
> Thanks Ben (and apologies about the double submission).
> 
> In this case, given the reference is not an RFC, that would explain why the
> script failed. Can we do a manual fix after the script has run to update
> the RFC?
> 
> On Tue, Oct 20, 2020 at 9:24 AM Benjamin Kaduk  wrote:
> 
> > On Tue, Oct 20, 2020 at 09:21:45AM -0700, RFC Errata System wrote:
> > >  --VERIFIER NOTES--
> > > Errata reports are for reporting issues with the authoritative RFC
> > version(s) as published by the RFC Editor.  RFC 8176 predates the usage of
> > the "v3 XML" format, so the plain text version is the authoritative one,
> > and thus questions of HTML links are irrelevant for it.
> >
> > For what it's worth, this "bad HTML link" situation occurs with some
> > regularity -- the "html" versions of non-v3-XML RFCs are created by running
> > a script over the text version.  The script uses heuristics to convert
> > certain types of text into links, and "Section " gets expanded to this
> > document unless followed by "of RFC ".  I believe this script is
> > open-source and patches would be welcome, though I don't know the location
> > of the source-code repository in question off the top of my head.
> >
> > -Ben
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> 
> 
> -- 
> *David Brossard*
> Sr. Director of Product Management
> Identity, Authentication, Federation, and Single Sign-On | Salesforce
> c: +1 502-922-6538 (US) | +1 236-333-6379 (Canada)
> Learn more about identity here
> <https://trailhead.salesforce.com/content/learn/modules/identity_basics/identity_basics_product>
> |
> Identity for Developers
> <https://developer.salesforce.com/developer-centers/identity/>

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Errata Rejected] RFC8176 (6314)

[Benjamin Kaduk]

On Tue, Oct 20, 2020 at 09:21:45AM -0700, RFC Errata System wrote:
>  --VERIFIER NOTES-- 
> Errata reports are for reporting issues with the authoritative RFC version(s) 
> as published by the RFC Editor.  RFC 8176 predates the usage of the "v3 XML" 
> format, so the plain text version is the authoritative one, and thus 
> questions of HTML links are irrelevant for it.

For what it's worth, this "bad HTML link" situation occurs with some
regularity -- the "html" versions of non-v3-XML RFCs are created by running
a script over the text version.  The script uses heuristics to convert
certain types of text into links, and "Section " gets expanded to this
document unless followed by "of RFC ".  I believe this script is
open-source and patches would be welcome, though I don't know the location
of the source-code repository in question off the top of my head.

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Towards an RFC Errata to RFC 7662 ?

[Benjamin Kaduk]

Hi Denis,

On Wed, Sep 02, 2020 at 10:39:07AM +0200, Denis wrote:
> Hi Ben,
> 
> This new thread, i.e."Towards an RFC Errata to RFC 7662 ?" is used to 
> discuss one of the topics raised in:
> Last Call:  (JWT 
> Response for OAuth Token Introspection) to Proposed Standard
> 
> Only the text relevant to this topic has been left.

Thank you for starting a new thread.  My apologies for taking so long to
reply to it; I have not been entirely healthy for a couple weeks and many
things have been left behind.

I do agree with Justin that a document update is the best way to
incorporate this kind of considerations -- with the caveat that generally
Roman, as responsible AD for the WG, would be processing errata reports
against the OAuth specs, if I was to be processing these proposals I would
probably have to mark them as "Hold for Document Update" due to the need to
ensure that they reflect WG consensus.  One further note inline...

> The text that has been discussed and polished would perfectly fit into 
> the Privacy Consideration section from RFC 7662.
> 
> Here it is again:
> 
> Implementers should be aware that a token introspection request lets
> the AS know when the client is accessing the RS, which can also
> indicate when the user is using the client. If this implication is
> not acceptable, implementers can use other means to carry access
> token data, e.g. directly transferring the data needed by the RS
> within the access token.
> 
> Privacy considerations sections do not change the protocol but only 
> provide some warnings. Warning the implementers is fine,
> but warning the users and the clients should also be considered.
> 
> Thanks to your observations, I noticed that the sentence "thecall 
> described in OAuth Introspection [RFC 7662] should be avoided"
> is not appropriate.So I propose an additional text which is relevant for 
> the users:
> 
> Token introspection is an optional feature primarily intended for
> clients that are unable to support structured access tokens,
> including their validation. However, the use of this call allows an
> AS to track where and exactly when clients or users have indeed
> presented an issued access token to a RS.
> 
> Some users or clients may be concerned that such a feature allows
> the AS to accurately trace them. If no Token introspection endpoint
> is published by an AS,
> users and clients can be confident that such tracing cannot happen.

I don't think that users and clients can be confident about this; AFAIK
out-of-band configuration of an introspection endpoint is possible.

-Ben

> On the contrary, when an introspection_endpoint is published by an
> AS [RFC8414],
> users and clients have no way to know whether the RS will be allowed
> to use it, nor whether it will effectively use it.If these
> implications are not acceptable,
> users or clients should not use an AS that publishes an
> introspection_endpoint.
> 
> Denis
> 
> > Hi all,
> >
> > On Mon, Aug 31, 2020 at 09:58:11AM +0200, Denis wrote:
> >> The last text that has been proposed on the list about this thread is
> >> the following:
> >>
> >> Implementers should be aware that a token introspection request lets the 
> >> AS know when the client is accessing the RS,
> >> which can also indicate when the user is using the client.  If this 
> >> implication is not acceptable, implementers can use
> >> other means to carry access token data, e.g. directly transferring the 
> >> data needed by the RS within the access token.
> >>
> >> The concerns of the implementers have nothing to do with the concerns of
> >> the Users. Such a text proposal has nothing to do with a "User consent".
> >>
> >> *Towards an RFC Errata to RFC 7662*
> >>
> >> Mike Jones wrote:
> >>
> >> I agree with Dick’s observation about the privacy implications of using
> >> an Introspection Endpoint. That’s why it’s preferable to not use one at all
> >>     and instead directly have the Resource understand the Access
> >> Token. One way of doing this is the JWT Access Token spec. There are
> >> plenty of others.
> >>
> >> I fully agree.
> >>
> >> RFC 7662 should have incorporated a more detailed content such as:
> >>
> >>    In OAuth 2.0 [RFC6749], the contents of tokens are opaque to
> >> clients. However, the contents of tokens is not intended to be opaque to
> >> RSs.
> >>    Token introspection is an OPTIONAL feature of an AS described in
> >> OAuth Introspection [RFC 7662] intended for clients that are unable
> >>    to support structured access tokens including their validation.
> >> The use of this call allows an AS to track where and when its clients
> >> have indeed
> >>    presented an issued access token. As soon as the RS knows the
> >> format of the access token, e.g. using structured token formats such as
> >>    JWT [RFC7519], and is able to validate its security features, the
> >> call described in OAuth 

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Benjamin Kaduk]

Hi all,

On Mon, Aug 31, 2020 at 09:58:11AM +0200, Denis wrote:
> The last text that has been proposed on the list about this thread is 
> the following:
> 
> Implementers should be aware that a token introspection request lets the 
> AS know when the client is accessing the RS,
>    which can also indicate when the user is using the client. If 
> this implication is not acceptable, implementers can use other means
>    to carry access token data, e.g. directly transferring the data 
> needed by the RS within the access token.
> 
> The concerns of the implementers have nothing to do with the concerns of 
> the Users. Such a text proposal has nothing to do with a "User consent".
> 
> *Towards an RFC Errata to RFC 7662*
> 
> Mike Jones wrote:
> 
> I agree with Dick’s observation about the privacy implications of using 
> an Introspection Endpoint. That’s why it’s preferable to not use one at all
>    and instead directly have the Resource understand the Access 
> Token. One way of doing this is the JWT Access Token spec. There are 
> plenty of others.
> 
> I fully agree.
> 
> RFC 7662 should have incorporated a more detailed content such as:
> 
>   In OAuth 2.0 [RFC6749], the contents of tokens are opaque to 
> clients. However, the contents of tokens is not intended to be opaque to 
> RSs.
>   Token introspection is an OPTIONAL feature of an AS described in 
> OAuth Introspection [RFC 7662] intended for clients that are unable
>   to support structured access tokens including their validation. 
> The use of this call allows an AS to track where and when its clients 
> have indeed
>   presented an issued access token. As soon as the RS knows the 
> format of the access token, e.g. using structured token formats such as
>   JWT [RFC7519], and is able to validate its security features, the 
> call described in OAuth Introspection [RFC 7662] should be avoided, 
> otherwise
>   the AS will know exactly when the introspection call has been made 
> and thus be able to make sure which client has attempted perform an access
>   to that RS and at which instant of time. As soon as this call is 
> supported by an AS, the client or the user have no way to prevent the RS 
> to use it.
> 
> It might be useful to add it, e.g. using an RFC Errata.

I do not believe this would be an appropriate usage of an Errata Report --
it changes the meaning of the RFC away from what the WG intended at the
time of publication.

Use of tokens that are just opaque DB handles (along with some form of
introspection) is desirable when a prominent threat is leakage of token
contents from the browser.  We have had numerous discussions over the years
of various ways in which information can leak from the browser, including
history APIs, malicious javascript, and more.  While these threats are not
always applicable in all deployment models, they are still present, just as
the threats that you propose we defend against are not always of concern in
all deployment models.  AFAICT, given the technologies currently available,
there is not one universal solution that will address all concerns, and
deployments will have to make a trade-off.  I think we need to acknowledge
that there are different deployment models and that (for example) giving
the user visibility into the token contents is not always desired, given
the other risks that the current mechanisms for providing that visibility
open up.

-Ben

P.S. your usage of the phrase "the User and his client" (below) suggests
that you are still picturing the client as being local to the user, as is
the case for, e.g., a TLS client or an IMAP client.  This is not the
original model for an OAuth, where the client can just as well be a
headless server in a cloud somewhere.

> *Differences with RFC 7662*
> 
> RFC 7662 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.
> 
> At a first glance, draft-ietf-oauth-jwt-introspection-response-09 seems 
> to be simply a JWT Response for OAuth Token Introspection
> instead of a JSON document representing the meta information surrounding 
> the token.
> 
> However, this is not the case since major differences can be identified.
> 
> RFC 7662 describes an OPTIONAL call able to return a JSON object with 
> the following top-level members: active (REQUIRED), scope (OPTIONAL),
> client_id (OPTIONAL), username (OPTIONAL), token_type (OPTIONAL), exp 
> (OPTIONAL), iat (OPTIONAL), nbf (OPTIONAL), sub (OPTIONAL),
> aud (OPTIONAL), iss (OPTIONAL), jti (OPTIONAL) and claims from the "JSON 
> Web Token Claims" registry (OPTIONAL).
> 
> draft-ietf-oauth-jwt-introspection-response-09 is able to return a JWT 
> as the introspection response. However, the request and the returned 
> information
> are not the same.
> 
> Section 4 (Requesting a JWT Response) only provides an example and does 

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

[Benjamin Kaduk]

Oops, that's my bad.  Thanks for the correction -- I've linked to your
message in the datatracker (but didn't bother to have the datatracker send
a third copy of my updated-again ballot position).

-Ben

On Thu, Aug 13, 2020 at 03:00:33PM -0600, Brian Campbell wrote:
> While some discussion of why explicit typing was not used might be useful
> to have, that thread started with a request for security considerations
> prohibiting use of the "sub" with a client ID value. Because such a request
> JWT could be repurposed for JWT client authentication. And explicit typing
> wouldn't help in that situation.
> 
> On Tue, Aug 11, 2020 at 2:50 PM Benjamin Kaduk via Datatracker <
> nore...@ietf.org> wrote:
> 
> >
> > --
> > COMMENT:
> > --
> >
> > [updated to note that, per
> > https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0eaE/
> > and the JWT BCP (RFC 8725), some discussion of why explicit typing is not
> > used would be in order]
> >
> >
> 
> -- 
> _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

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

[Benjamin Kaduk]

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
> 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" 

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

[Benjamin Kaduk via Datatracker]

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:
--

[updated to note that, per 
https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0eaE/
and the JWT BCP (RFC 8725), some discussion of why explicit typing is not used 
would be in order]

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.

Please update the Content-Length in the example in Section 5.2.3.


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
[...]"?

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?

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.

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?).

Section 6.x

(nit) I suggest consistency in subsection headings, so, e.g., "JWE
Encrypted Request Object" and "JWS Signed Request Object".

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 t

Re: [OAUTH-WG] swapping a jwsreq/JAR JWT for a client authentication JWT

[Benjamin Kaduk]

On Tue, Aug 11, 2020 at 02:35:20PM -0600, Brian Campbell wrote:
> I also suspect the Jwsreq authors won't respond to this and the
> request/suggestion will be ignored. Which is discouraging. I realize it's
> late in the process for this document but it's been in IESG Evaluation
> since early 2017. And the recent ballot comments
> https://mailarchive.ietf.org/arch/msg/oauth/FMljWETMEkGTI4pUluqIqtAJ_9A/
> suggests changes to the draft should still be forthcoming. So also adding a
> brief statement to the security considerations doesn't seem inconceivable.

Yup, I expect further changes to the document before publication.

Thanks for resurfacing this topic; I updated my ballot position to include
a reference to it.

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Benjamin Kaduk via Datatracker]

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.

Please update the Content-Length in the example in Section 5.2.3.


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
[...]"?

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?

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.

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?).

Section 6.x

(nit) I suggest consistency in subsection headings, so, e.g., "JWE
Encrypted Request Object" and "JWS Signed Request Object".

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.

Section 6.3

I'd suggest reiterating here the requirement to verify "client_id"
consistency between Request Object and

Re: [OAUTH-WG] Product Support for RFC8414 well-known URIs

[Benjamin Kaduk]

On Tue, Jun 09, 2020 at 09:42:27AM +0200, Daniel Fett wrote:
> Am 09.06.20 um 00:50 schrieb Benjamin Kaduk:
> > On Mon, Jun 08, 2020 at 11:15:07AM +0200, Daniel Fett wrote:
> >> Hi Filip,
> >>
> >> Thanks for your answers!
> >>
> >> I'm not quite sure if the wording in my question was clear: My main
> >> concern is the difference between
> >> https://example.com/some/path*/.well-known/oauth-authorization-server*
> >> and
> >> https://example.com*/.well-known/oauth-authorization-server*/some/path,
> >> i.e., the usage of the well-known URI as a postfix or as an infix.
> > .well-known is only defined at the root of the path component of a URI.
> > Usage such as
> > https://example.com/some/path*/.well-known/oauth-authorization-server* is
> > noncompliant with RFC 5785.
> 
> I know, but my impression is that since OIDC did it this way, some
> clients are expecting the same behavior for RFC8414. Thus the question
> if AS should be allowed or even required to offer the postfix variant in
> an ecosystem.

Hmm, we don't seem to have gotten many replies on this question.  My own
individual opinion is "no", roughly on the grounds that doing it in the
wild starts a slippery slope and we don't want to get in the business of
encouraging BCP 190 violations.

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Product Support for RFC8414 well-known URIs

[Benjamin Kaduk]

On Mon, Jun 08, 2020 at 11:15:07AM +0200, Daniel Fett wrote:
> Hi Filip,
> 
> Thanks for your answers!
> 
> I'm not quite sure if the wording in my question was clear: My main
> concern is the difference between
> https://example.com/some/path*/.well-known/oauth-authorization-server*
> and
> https://example.com*/.well-known/oauth-authorization-server*/some/path,
> i.e., the usage of the well-known URI as a postfix or as an infix.

..well-known is only defined at the root of the path component of a URI.
Usage such as
https://example.com/some/path*/.well-known/oauth-authorization-server* is
noncompliant with RFC 5785.

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

[Benjamin Kaduk]

Hi Denis,

On Tue, Jun 02, 2020 at 10:20:36AM +0200, Denis wrote:
> Hi Benjamin,
> 
> Responses are between the lines.
> 
> > On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote:
> >> Hi Benjamin,
> >>> On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote:
>  Since then, I questioned myself how a client would be able to 
>  request an access token that would be *strictly compliant with this 
>  Profile*.
> >>> I don't understand why this is an interesting question to ask. The 
> >>> access token and interpretation thereof is (AIUI) generally seen as 
> >>> an internal matter between AS and RS, with the client having no need 
> >>> to care about the specifics.
> >> This document is*_a_* Profile for OAuth 2.0 Access Tokens. It is not 
> >> _*the*_ Profile for *_all_ *OAuth 2.0 Access Tokens.
> > Sure. But (in my understanding), in common usage, the contents and 
> > interpretation of the access token is set by common agreement between 
> > AS and RS, with the client serving only as a "dumb" channel for 
> > transporting the token. That is, we're providing a token format that 
> > an RS and AS can agree to use, most likely for all tokens issued by 
> > the AS for that RS. I don't know of any existing mechanisms, or desire 
> > for such mechanisms by deployments, for using a different token format 
> > for different tokens issued by a given AS for a given RS.
> 
> Since this document is *_a_* Profile for OAuth 2.0 Access Tokens, it 
> means that potentially other Profiles could be defined in the future.
> In the request, there is no parameter for a client to indicate that it 
> wants a JWT conformant to _this_ profile and no parameter either
> in the response to indicate to the client that it got a JWT that is 
> conformant to _this_ profile.

I don't think my point came through clearly.  Right now, the AS and RS have
to negotiate by some out-of-band means what token format and details to use
for tokens issued by AS with RS in audience, and there is not a
"well-known" description of how to use JWT to do so.  The goal of this
document is to simplify the out-of-band negotiation between AS and RS, so
they can just say "use RFC " instead of having to specify a lot of
details individually.  Nowhere does the client come into the current
negotiation of what token format to use, and the act of specifying a
profile of JWT for this usage does not create a requirement for the client
to be included in the negotiation.

Now, whether or not to include the client in this negotiation (and whether
or not to make the choice of token format finer-grained) may be a topic
worth discussion in its own right, but that discussion is untethered from
specifying a profile of JWT to simplify AS/RS negotiations.

> The processing mandated in the document of a request made by a client to 
> an AS only applies for a request conformant to this profile
> which may or may not include a scope parameter and which may or may not 
> include a "resource" parameter (and, if it does not, shall
> include an "aud" claim). Currently, it is not possible to make a 
> difference between a JWT request or response conformant to this profile
> and other JWT requests or responses.

I don't see where this document places constraints on a "conformant
request" made by a client; could you point that out to me?

(FWIW, the section heading for section 3 seems needlessly confusing, as the
contents of the section do not seem to say anything about specifically
requesting a JWT token.  I can see how this heading might cause some
confusion.)

> > Attempting to have the client provide input that would affect such a 
> > mechanism seems like complexity with no market demand; a "solution in 
> > search of a problem" as it were. Is there some pent-up demand among 
> > OAuth deployments that I'm not aware of? I freely admit to not being 
> > very on top of the broad spectrum of what's deployed...
> >> 1) A client may wish to obtain an Access Token that corresponds to 
> >> this Profile because, for example, this document mandates the "sub" 
> >> claim to be present". Hence, the content of the Access Token is not 
> >> totally "/an internal matter between AS and RS/". However, I have not 
> >> understood how a client could request an Access Token that 
> >> corresponds to *_this_***Profile, since there is no mandatory 
> >> parameter in the request (both the "scope" parameter and the 
> >> "resource" parameter are optional). In the future, we could define 
> >> _*another*_**Profile. Hence, there is the same question:  How could a 
> >> client request an Access Token that corresponds to *_that 
> >> other_***Profile ? 2) When getting a JWT,  how can the client make 
> >> sure that the access token it got is compliant with this Profile ? 
> >> RFC 8725 states in section 3.11 : 3.11. Use Explicit Typing 
> >> Sometimes, one kind of JWT can be confused for another. If a 
> >> particular kind of JWT is subject to such confusion, that JWT can 
> >> include an 

Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

[Benjamin Kaduk]

On Mon, Jun 01, 2020 at 10:06:22PM +0530, Janak Amarasena wrote:
> Hi all,
> 
> My apologies, if this was already discussed.
> 
> In section *4*. Validating JWT Access Tokens
> <https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07#section-4> 
> it
> is stated;
> 
> The resource server MUST handle errors as described in section 3.1 of
>[RFC6750] <https://tools.ietf.org/html/rfc6750#section-3.1>.  In
> particular, in case of any failure in the validation
>checks listed above the *authorization server* response MUST include
>the error code "invalid_token".
> 
> 
> 
> 
> Should this be;
> 
> ... above the *resource server* response MUST include the error code
> "invalid_token".

It does look like it should be the resource server there, yes.
Good catch, and thanks for mentioning it!

-Ben

> 
> If that is not the case, which kind of scenarios would occur for an AS to
> respond with the error code "invalid_token"?
> 
> Best Regards,
> Janak Amarasena
> 
> On Sun, May 31, 2020 at 2:25 AM Benjamin Kaduk  wrote:
> 
> > On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote:
> > > Hi Benjamin,
> > > > On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote:
> > > >> Since then, I questioned myself how a client would be able to request
> > an
> > > >> access token that would be
> > > >> *strictly compliant with this Profile*.
> > > > I don't understand why this is an interesting question to ask.  The
> > access
> > > > token and interpretation thereof is (AIUI) generally seen as an
> > internal
> > > > matter between AS and RS, with the client having no need to care about
> > the
> > > > specifics.
> > >
> > > This document is*_a_* Profile for OAuth 2.0 Access Tokens. It is not
> > > _*the*_ Profile for *_all_ *OAuth 2.0 Access Tokens.
> >
> > Sure.  But (in my understanding), in common usage, the contents and
> > interpretation of the access token is set by common agreement between AS
> > and RS, with the client serving only as a "dumb" channel for transporting
> > the token.  That is, we're providing a token format that an RS and AS can
> > agree to use, most likely for all tokens issued by the AS for that RS.  I
> > don't know of any existing mechanisms, or desire for such mechanisms by
> > deployments, for using a different token format for different tokens issued
> > by a given AS for a given RS.  Attempting to have the client provide input
> > that would affect such a mechanism seems like complexity with no market
> > demand; a "solution in search of a problem" as it were.  Is there some
> > pent-up demand among OAuth deployments that I'm not aware of?  I freely
> > admit to not being very on top of the broad spectrum of what's deployed...
> >
> > > 1) A client may wish to obtain an Access Token that corresponds to this
> > > Profile because, for example,
> > > this document mandates the "sub" claim to be present". Hence, the
> > > content of the Access Token is not
> > > totally "/an internal matter between AS and RS/".
> > >
> > > However, I have not understood how a client could request an Access
> > > Token that corresponds to *_this_***Profile,
> > > since there is no mandatory parameter in the request (both the "scope"
> > > parameter and the "resource" parameter are optional).
> > >
> > > In the future, we could define _*another*_**Profile. Hence, there is the
> > > same question:  How could a client request an Access Token
> > > that corresponds to *_that other_***Profile ?
> > >
> > > 2) When getting a JWT,  how can the client make sure that the access
> > > token it got is compliant with this Profile ?
> > >
> > > RFC 8725 states in section 3.11 :
> > >
> > > 3.11. Use Explicit Typing
> > > Sometimes, one kind of JWT can be confused for another. If a
> > > particular kind of JWT is subject to such confusion,
> > > that JWT can include an explicit JWT type value, and the validation
> > > rules can specify checking the type (...).
> > > Explicit JWT typing is accomplished by using the "typ" Header
> > > Parameter.
> > >
> > > Wouldn't be wise to include an explicit JWT type value for JWTs
> > > conformant to this Profile ?
> >
> > In the model where the client is a "dumb" communications channel, this
> >

Re: [OAUTH-WG] [Technical Errata Reported] RFC7636 (6179)

[Benjamin Kaduk]

Hi Dmitry,

Thanks for clarifying the motivation.
I think it's shifted my stance a bit, to lean more towards classifying as
"editorial" (in that the protocol in the RFC itself is not affected) with
status of "Hold for document update".

-Ben

On Tue, Jun 02, 2020 at 12:32:48AM +, Dmitry Khlebnikov wrote:
> Naveen,
> 
> My concern with that section is that it provides misleading information about 
> salting and that was the primary reason I was recommending to remove it.  
> However, knowing that we cannot amend what was already released as RFC 
> (Unfortunately, somehow I missed the discussion in 2014 when I could have 
> influenced that part), even if we make an errata saying that this part of the 
> RFC is not applicable and one should not even think about applying a salt to 
> a single unique hash the number of people confused and not being aware of the 
> errata is going to be significant. Still, I think it is the right thing to do 
> for those who are seeking for the information.
> 
> What prompted me to write it up (the request for errata) was that in a week I 
> had several people approaching me in regard to this RFC and asking for advice 
> (I am a Senior Security Adviser for one of Australia's largest realestate 
> advertising platforms).  This coupled with the overall misunderstanding of 
> salting (a techique against rainbow tables) and peppering (a technique to 
> protect hashes from bruteforcing once the dataset is exfiltrated) of hashes 
> pushed me to reach out.
> 
> --
> Dmitry Khlebnikov
> Senioe Security Adviser // REA Group
> +61 428 425291
> 
> ____
> From: Naveen Agarwal 
> Sent: Tuesday, 2 June 2020 03:47
> To: Rifaat Shekh-Yusef
> Cc: Benjamin Kaduk; Dmitry Khlebnikov; n-sakim...@nri.co.jp; oauth; RFC 
> Errata System
> Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC7636 (6179)
> 
> [External Email]
> 
> 
> As one of the author, writing from my persona email.
> 
> I think at the time someone must have suggested that we should add a salt for 
> the code_verifier before hashing and this was added to explain that there is 
> no need to do that. As Dmitry agreed that salting is not really applicable in 
> this case and I agree that  the section could have been written in a better 
> way. But I do think when people try to implement they may ask the same 
> question as they have been told again and again that you should salt your 
> hashes. So leaving it in place doesn't hurt (as it is not making any bad 
> recommendation but not doing a great job justifying why we didn't add 
> salting).
> 
> Thanks
> 
> Naveen
> 
> On Sun, May 31, 2020 at 12:41 PM Rifaat Shekh-Yusef 
> mailto:rifaat.s.i...@gmail.com>> wrote:
> Nat, John,
> 
> Do you guys have any thoughts on this errata?
> 
> Regards,
>  Rifaat
> 
> 
> On Sat, May 23, 2020 at 4:25 PM Benjamin Kaduk 
> mailto:ka...@mit.edu>> wrote:
> Authors, WG, any comments?
> 
> Right now the likely dispositions seem to me to be Editorial/HFDU or
> Rejected; the text is noting that salting is not used and attempting to
> give an explanation of why that's the right choice.  It's not clear that
> the WG was in error to include some such discussion at the time of
> publication, which is essentially what this errata report is claiming.
> 
> Thanks,
> 
> Ben
> 
> On Mon, May 18, 2020 at 03:04:26AM -0700, RFC Errata System wrote:
> > The following errata report has been submitted for RFC7636,
> > "Proof Key for Code Exchange by OAuth Public Clients".
> >
> > --
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid6179
> >
> > --
> > Type: Technical
> > Reported by: Dmitry Khlebnikov 
> > mailto:dmitry.khlebni...@rea-group.com>>
> >
> > Section: 7.3
> >
> > Original Text
> > -
> > 7.3.  Salting the code_challenge
> >
> >To reduce implementation complexity, salting is not used in the
> >production of the code challenge, as the code verifier contains
> >sufficient entropy to prevent brute-force attacks.  Concatenating a
> >publicly known value to a code verifier (containing 256 bits of
> >entropy) and then hashing it with SHA256 to produce a code challenge
> >would not increase the number of attempts necessary to brute force a
> >valid value for code verifier.
> >
> >While the "S256" transformation is like hashing a password, there are
> >important differences.  Passwords tend to be relatively low-entropy
> >

Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187)

[Benjamin Kaduk]

On Sun, May 31, 2020 at 12:58:54PM -0500, Pete Resnick wrote:
> On 31 May 2020, at 12:47, Barry Leiba wrote:
> 
> >> But 
> >> https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/, 
> >> in particular:
> >>
> >> Only errors that could cause implementation or deployment problems or 
> >> significant confusion should be Verified.
> >> Things that are clearly wrong but could not cause an implementation 
> >> or deployment problem should be Hold for Document Update.
> >> Typographical errors which would not cause any confusions to 
> >> implementation or deployments should be Hold for Document Update.
> >>
> >> Did something change these criteria?
> >
> > They're guidelines, not absolute rules, and judgment is expected.
> 
> Sure, but I was replying to Ben's statement that, "The new text is 
> clearly the right thing, and there is no need to debate it if/when the 
> document gets updated.  'Don't hold it; do it now', so to speak". That's 

To be clear, that was an off-the-cuff remark and not a considered opinion.

> not what Verified ever meant before. If the meaning has changed, that's 
> fine, but someone should let the community know and update the IESG 
> Statement. (Personally, I'm all for that, as I've found the current 
> definitions absurd and confusing. All clearly wrong Editorial errata 

They're also not especially internally consistent.  The first point quoted
lists causing "significant confusion" as grounds for Verified, but the
second point doesn't, even though it lists the other two items and one
might expect it to mirror the first point.

Would having a link to go a completely different document than one should
be seeing cause "significant confusion"?  For some people, I think it
would.  I've certainly had such cases, myself, before -- IIRC I put a
Discuss on a document that referenced RFC 7519 when it meant 7159 (in that
case, the "wrong" document was close-enough to topical to be plausible,
albeit incorrect).

-Ben

> should be marked "Verified", IMO.) But that's not about applying 
> judgement; that's changing the definition of the terms used.
> 
> pr
> -- 
> Pete Resnick https://www.episteme.net/
> All connections to the world are tenuous at best

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request))

[Benjamin Kaduk]

On Wed, May 27, 2020 at 07:20:29PM +0200, Denis wrote:
> As indicated in the abstract:
> 
> "This document introduces the ability to send request parameters in
> a JSON Web Token (JWT) instead,
>    which allows the request to be signed with JSON Web Signature (JWS)".
> 
> This approach has a major consequence which is not indicated in the 
> "Privacy Considerations section:
> the AS will have the knowledge of these request parameters such as 
> "please let me make a payment with the amount of 45 Euros"
> or "please give me read access to folder A and write access to file X".
> 
> Such an approach has privacy issues which are currently not documented 
> in the Privacy Considerations section.
> 
> The AS would be in a position to know, not only which resources servers 
> are going to be accessed, but also what kind of operations
> are going to be performed by its clients on the resource servers. With 
> such an approach, ASs will have a deep knowledge of every
> operation that can be performed by a user on every RS.
> 
> As a consequence, the AS would also be in a position to trace the 
> actions performed by its users on the resources servers.
> 
> Other approaches that are more "privacy friendly" should be considered 
> to address the initial problem.

Do you have the start of a list of such other approaches to seed the
discussion?  There seemms to be some inherent tension between the
authorization server knowing what it is authorizing and the privacy
properties you are advocating...

Thanks,

Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187)

[Benjamin Kaduk]

The new text is clearly the right thing, and there is no need
to debate it if/when the document gets updated.  "Don't hold
it; do it now", so to speak -- and noting that (my
understanding/recollection of) the plan for
https://www.rfc-editor.org/rfc/inline-errata/rfc7800.html is that only
verified errata, not those in other states, will be displayed.

(Yes, that link 404s at the moment, I assume a caching issue.)

-Ben

On Sat, May 30, 2020 at 10:55:01PM -0500, Pete Resnick wrote:
> "Verified", not "Hold For Document Update"?
> 
> pr
> 
> On 30 May 2020, at 20:34, RFC Errata System wrote:
> 
> > The following errata report has been verified for RFC7800,
> > "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)".
> >
> > --
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid6187
> >
> > --
> > Status: Verified
> > Type: Editorial
> >
> > Reported by: Pete Resnick 
> > Date Reported: 2020-05-26
> > Verified by: Benjamin Kaduk (IESG)
> >
> > Section: 7.1
> >
> > Original Text
> > -
> >[JWK]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
> >   DOI 10.17487/RFC7157, May 2015,
> >   <http://www.rfc-editor.org/info/rfc7517>.
> >
> >
> > Corrected Text
> > --
> >[JWK]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
> >   DOI 10.17487/RFC7517, May 2015,
> >   <http://www.rfc-editor.org/info/rfc7517>.
> >
> >
> > Notes
> > -
> > DOI has a typo: 7157 instead of 7517.
> >
> > --
> > RFC7800 (draft-ietf-oauth-proof-of-possession-11)
> > --
> > Title   : Proof-of-Possession Key Semantics for JSON Web 
> > Tokens (JWTs)
> > Publication Date: April 2016
> > Author(s)   : M. Jones, J. Bradley, H. Tschofenig
> > Category: PROPOSED STANDARD
> > Source  : Web Authorization Protocol
> > Area: Security
> > Stream  : IETF
> > Verifying Party : IESG
> 
> 
> -- 
> Pete Resnick https://www.episteme.net/
> All connections to the world are tenuous at best

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

[Benjamin Kaduk]

On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote:
> Hi Benjamin,
> > On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote:
> >> Since then, I questioned myself how a client would be able to request an
> >> access token that would be
> >> *strictly compliant with this Profile*.
> > I don't understand why this is an interesting question to ask.  The access
> > token and interpretation thereof is (AIUI) generally seen as an internal
> > matter between AS and RS, with the client having no need to care about the
> > specifics.
> 
> This document is*_a_* Profile for OAuth 2.0 Access Tokens. It is not 
> _*the*_ Profile for *_all_ *OAuth 2.0 Access Tokens.

Sure.  But (in my understanding), in common usage, the contents and
interpretation of the access token is set by common agreement between AS
and RS, with the client serving only as a "dumb" channel for transporting
the token.  That is, we're providing a token format that an RS and AS can
agree to use, most likely for all tokens issued by the AS for that RS.  I
don't know of any existing mechanisms, or desire for such mechanisms by
deployments, for using a different token format for different tokens issued
by a given AS for a given RS.  Attempting to have the client provide input
that would affect such a mechanism seems like complexity with no market
demand; a "solution in search of a problem" as it were.  Is there some
pent-up demand among OAuth deployments that I'm not aware of?  I freely
admit to not being very on top of the broad spectrum of what's deployed...

> 1) A client may wish to obtain an Access Token that corresponds to this 
> Profile because, for example,
> this document mandates the "sub" claim to be present". Hence, the 
> content of the Access Token is not
> totally "/an internal matter between AS and RS/".
> 
> However, I have not understood how a client could request an Access 
> Token that corresponds to *_this_***Profile,
> since there is no mandatory parameter in the request (both the "scope" 
> parameter and the "resource" parameter are optional).
> 
> In the future, we could define _*another*_**Profile. Hence, there is the 
> same question:  How could a client request an Access Token
> that corresponds to *_that other_***Profile ?
> 
> 2) When getting a JWT,  how can the client make sure that the access 
> token it got is compliant with this Profile ?
> 
> RFC 8725 states in section 3.11 :
> 
> 3.11. Use Explicit Typing
> Sometimes, one kind of JWT can be confused for another. If a
> particular kind of JWT is subject to such confusion,
> that JWT can include an explicit JWT type value, and the validation
> rules can specify checking the type (...).
> Explicit JWT typing is accomplished by using the "typ" Header
> Parameter.
> 
> Wouldn't be wise to include an explicit JWT type value for JWTs 
> conformant to this Profile ?

In the model where the client is a "dumb" communications channel, this
question does not seem interesting.  But the related question of "how can
the RS make sure that the access token it got was generated according to
this profile?" does seem interesting, and seems like it would benefit from
the same proposed solution.

> This relates to an email posted by Dominick Baier under the topic "JAR: 
> JWT typ" on May 19 :
> 
> This has been brought up before - but no response.
> 
> Either I can’t find it - or it is missing. But is the setting the
> JWT typ explicitly mentioned somewhere?

It is fairly likely that I will remember to ask about explicit "typ" usage
if I'm still on the IESG when this document gets there: I think I've been
making a habit of doing so.

Thanks,

Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Technical Errata Reported] RFC7636 (6179)

[Benjamin Kaduk]

Authors, WG, any comments?

Right now the likely dispositions seem to me to be Editorial/HFDU or
Rejected; the text is noting that salting is not used and attempting to
give an explanation of why that's the right choice.  It's not clear that
the WG was in error to include some such discussion at the time of
publication, which is essentially what this errata report is claiming.

Thanks,

Ben

On Mon, May 18, 2020 at 03:04:26AM -0700, RFC Errata System wrote:
> The following errata report has been submitted for RFC7636,
> "Proof Key for Code Exchange by OAuth Public Clients".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6179
> 
> --
> Type: Technical
> Reported by: Dmitry Khlebnikov 
> 
> Section: 7.3
> 
> Original Text
> -
> 7.3.  Salting the code_challenge
> 
>To reduce implementation complexity, salting is not used in the
>production of the code challenge, as the code verifier contains
>sufficient entropy to prevent brute-force attacks.  Concatenating a
>publicly known value to a code verifier (containing 256 bits of
>entropy) and then hashing it with SHA256 to produce a code challenge
>would not increase the number of attempts necessary to brute force a
>valid value for code verifier.
> 
>While the "S256" transformation is like hashing a password, there are
>important differences.  Passwords tend to be relatively low-entropy
>words that can be hashed offline and the hash looked up in a
>dictionary.  By concatenating a unique though public value to each
>password prior to hashing, the dictionary space that an attacker
>needs to search is greatly expanded.
> 
>Modern graphics processors now allow attackers to calculate hashes in
>real time faster than they could be looked up from a disk.  This
>eliminates the value of the salt in increasing the complexity of a
>brute-force attack for even low-entropy passwords.
> 
> Corrected Text
> --
> 
> 
> Notes
> -
> The section misrepresents the information about "salting" and the whole idea 
> of "salting" is not applicable to a standalone hash.  I suggest to drop the 
> entire
> section as irrelevant to the rest of the standard.
> 
> For some reason the section implies that "salting" is protecting and 
> increasing
> entropy of a single hash, which is not what "salting" is about and is not the
> reason for the technique.  The section is also making a speculative 
> assumptions
> about the low-entropy tendency in password hashes and makes an incorrect
> conclusion on the benefits of "salting" for a password hash.
> 
> One could argue that the entropy and the complexity required to bruteforce a 
> hash
> and a salted hash for the same password (where the same hashing algorithm is
> applied) are approximately the same in most cases (or just slightly more
> complex for the salted version if the producer of the hash used a non-standard
> routine in relation of mixing in the salt, e.g. instead of appending the salt
> it inserts in in the middle of the password to be hashed).  In any case, that
> public data is already known to the attacker and it is just a matter of the
> configuration for the bruteforcing tool (such as JohnTheRipper) to incorporate
> the knowledge.
> 
> Just as an illustration: consider an example password ('abc'), an example salt
> ('123'), and that the hash is generated using a concatinated version of these
> two (e.g. HASH('abc123')).  Since the salt is included with the hash in plain
> text, the bruteforcer would just need to set their tool up with the "^.*123$"
> pattern making the salt essentially a string terminator which is not affecting
> the bruteforce effort in any way).
> 
> More and more people I meet are confused about the problem area the "salting"
> technique was invented to address: it is to increase the entropy of a set of
> passwords, so the same password would not result in the same hash value, with
> the primary goal is to prevent attackers to be able to re-use pre-calculated
> hashes (e.g. rainbow hash tables) or, in the early stages of the attack, to
> make it impossible to quickly assess what hashes the attacker should focus on
> (e.g.  when you have 1000 hashes and without salts you can easily spot that
> some hashes are the same, which means breaking these one would gain much more
> in comparison to unique hashes in the same set).
> 
> This being said, I am suggesting to drop section 7.3 completely as 
> irrelevant, 
> since what we currently have is very confusing and seeds unnecessary and
> wrong ideas that "salting" can improve the security of a single hash by 
> itself.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to 

Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

[Benjamin Kaduk]

On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote:
> 
> Since then, I questioned myself how a client would be able to request an 
> access token that would be
> *strictly compliant with this Profile*.

I don't understand why this is an interesting question to ask.  The access
token and interpretation thereof is (AIUI) generally seen as an internal
matter between AS and RS, with the client having no need to care about the
specifics.  To my knowledge, this WG has not previously given guidance
indicating that the client should be involved or specifics for how to do
so, and I do not remember seeing WG agreement that this should change.

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

[Benjamin Kaduk]

My apologies for a tangent on an already-long thread...

On Fri, May 08, 2020 at 08:50:16AM +0200, Daniel Fett wrote:
> 
> Yes, this will make a number of implementations non-spec-compliant, but
> I do not think that this is a huge problem. Software needs to adapt all
> the time and a software that has not been changed in a while is probably
> not one you would want to use anyway. We are setting a new goal for
> implementations to meet and eventually, maintained implementations will
> get there.

It's probably worth an occasional reminder that though this is true for the
web-facing software most of us work on, it's not actually universally true
for *all* software.  Things that are rated as safety-critical software, or
the SCADA systems running billion-dollar industrial processes that only
take downtime for hardware upgrades, are written in a rather different
ecosystem.  :)

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Benjamin Kaduk]

Hi Denis,

Sorry for the slow response.  I had several deadlines this week and
couldn't think much farther ahead than the next one, so my INBOX fell
behind.

On Mon, May 04, 2020 at 12:36:05PM +0200, Denis wrote:
> Hello Benjamin,
> 
> First of all, you don't need to use an aggressive language to state your 
> opinion.

I would appreciate a little more clarity on which language comes across as
"aggressive"; I was trying very hard to stick to what I see as the facts:

- many people are frustrated with these long discussions that continue to
  rehash similar points and involve people having a hard time seeing each
  others' worldview
- you are making proposals for changes to this document that would
  represent drastic changes from previous specifications that are used by
  the current document (and are drastic changes from current practice),
  without acknowledging that they are in fact drastic changes to the core
  protocol

Please accept my apologies for however I deviated from that goal.

I am trying to get us to a place where we can have productive discussions
and improve the quality of our protocols.  Right now I don't think we're
having very productive discussions; in fact, we're holding up progress on a
document that looks likely to become widely deployed by asking it to do
more than is reasonable for it to do.

> Please follow BCP 54, i.e. RFC 7154, issued inMarch 2014 with the 
> following title:"IETF Guidelines for Conduct". In particular:
> 
> " Regardless of these individual differences, participants treat
> their colleagues with respect as persons especially
>     when it is difficult to agree with them: treat other
> participants as you would like to be treated ".
> 
> I wrote:
> 
> (...)
> 
>      I will go one step further: if the client wants to inspect the 
> token and
>      if the format of the token is unknown to the client, then the client
> will simply stop its further transmission. For some clients, preserving 
> their
> privacy may be more important than performing an access to a RS.
> 
> You responded :
> 
>     That may be true, but I agree with Vittorio that this document needs to
>     strongly discourage clients from doing so, since they would 
> be**_breaking _*
> *_a __protocol invariant_ if they do.
> 
> If "this may be true", then you should consider that the token 
> inspection by a client may be useful and thus should not be prevented.

I do in fact agree that token inspection by a client can be useful in at
least some situations.  However, RFC 6749 is quite clear that "the [access
token] is usually opaque to the client".  A requirement that the access
token MUST be inspectable by the client is incompatible with something that
"is usually opaque to the client".

> However, there is no guarantee that it may always be performed.

I agree that this is the current state of affairs.

> You are using the wording" _breaking a protocol invariant_". In which 
> RFC (related to OAuth) has such a "protocol invariance" been first 
> mandated ?

RFC 6749, per above.

> I attempted to find an RFC using the wording "protocol invariant". I 
> found RFC 8546 (Wire Image) issued in April 2019 dealing in section 4.1
> with the topic " Declaring Protocol Invariants", using the following terms:
> 
> Declaring a protocol's invariants represents a promise made by the 
> protocol's developers that certain bits in the wire image, and behaviors
>     observable in the wire image, will be preserved through the 
> specification of all future versions of the protocol.

Perhaps my usage of the term "protocol invariant" was confusing or
inappropriate.  I meant to say that you are trying to change a property of
the core protocol specification; whether or not it is best described as an
"invariant" is immaterial to my point.  In other words, a generic OAuth 2.0
client has to be prepared to deal with access tokens that are opaque to it.

> Using these explanations, I have difficulties to understand how 
> preventing the content of a JWT to be inspected by a client may be 
> considered
> as "a promise made by the protocol's developers that certain bits in the 
> wire, and behaviors observable in the wire, will be preserved
> through the specification of all future versions of the protocol".
> 
> I probably missed something. Would you be able to explain ?

(I tried to above.)

> A second point:
> 
> As a co-author of RFC 3161 published in August 2001 and of RFC 36268 
> published in November 2003 to name a few of the RFCs
> to which I contributed, I am not aware of any reference to an ISO 
> document made into a RFC. This seems to be a common practice.
> When I used the term "refer", I was not asking to place a reference to 
> an ISO document in this working draft but to allow everybody in
> the WG to have the ability to have a look at its content (and for free). 

Ah, I misunderstood you then; sorry about that.
Using readily-available documents where someone has already written down

Re: [OAUTH-WG] DPoP draft-ietf-oauth-dpop-0 Client collaborative attacks

[Benjamin Kaduk]

Hi Denis,

On Fri, May 01, 2020 at 10:47:18AM +0200, Denis wrote:
>Comments on draft-ietf-oauth-dpop-00.
> 
>1) In section 9 (Security considerations), the text states:
> 
>DPoP does not, however, achieve the
>   same level of protection as TLS-based methods such as OAuth Mutual
>   TLS [RFC8705] or OAuth Token Binding [I-D.ietf-oauth-token-binding]
>   (see also Section 9.1 and Section 9.4).
> 
>draft-ietf-oauth-token-binding-08 [i.e. I-D.ietf-oauth-token-binding]
>expired on April 22, 2019,
>thus it does not seem adequate to refer to it.

It can still be useful to refer to technology that ended up not getting
deployed, for comparison against the work in questionn.

>2)  The text states:
> 
>9.1.  DPoP Proof Replay
> 
>   If an adversary is able to get hold of a DPoP proof JWT, the
>   adversary could replay that token at the same endpoint (the HTTP
>   endpoint and method are enforced via the respective claims in the
>   JWTs).
> 
>This is true, but there is a worse case:  if a client legitimately obtains
>a DPoP proof JWT and collaborates
>with another client, then it can provide it to that other client.

Would we not consider one or both such clients to be "an adversary" in that
situation?  They are, after all, behaving contrary to the expected flow.

>3)  The text states:
> 
>   9.4.  Message Integrity
> 
>   DPoP does not ensure the integrity of the payload or headers of
>   requests.  The signature of DPoP proofs only contains the HTTP URI
>   and method, but not, for example, the message body or other request
>   headers.
> 
>   This is an intentional design decision to keep DPoP simple to use,
>   but as described, makes DPoP potentially susceptible to replay
>   attacks where an attacker is able to modify message contents and
>   headers.  In many setups, the message integrity and confidentiality
>   provided by TLS is sufficient to provide a good level of protection.
> 
>DPoP alone or DPoP used in conjunction with TLS does not provide any
>protection in case of collusion attacks
>between collaborative clients.

Do you think that the reader would expect such protection in the absence of
text in the security considerations section?
My personal expectation is that the reader would not expect protection
against a client that colludes with some other (malicious) party, and that
such a client would itself be deemed malicious.

Thanks,

Ben

>Collaborative attacks between clients cannot be countered using
>software-only implementations.
>It should also be noticed that the use of secure elements to only protect
>private keys is insufficient,
>since a collaborative client can still perform all the cryptographic
>computations needed by the other client.
> 
>These considerations about collaborative clients should be added into the
>security considerations section.
> 
>Denis

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Microsoft feedback on DPoP during April 2020 IIW session

[Benjamin Kaduk]

On Fri, May 01, 2020 at 02:29:02AM +, Mike Jones wrote:
>   *   Is the DPoP signature really needed when requesting a bound token?  It 
> seems like the worst that could happen would be to create a token bound to a 
> key you don't control, which you couldn't use.  Daniel expressed concern 
> about this enabling substitution attacks.

Substitution and confused deputy attacks, yes.  I would feel a lot better
if the signature is required when requesting the bound token; a fair bit of
extra analysis would be needed to try to remove it.

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Benjamin Kaduk]

Hi Denis,

You seem to be continuing to be operating under incorrect assuptions about
how OAuth 2.0 works, and have proceeded to make long chains of reasoning
that, unfortunately, are not based on a solid foundation.  In order to
reduce the amount of frustration amongst all participants, in the future I
strongly suggest that you make sure you have the fundamentals correct
before going into long chains of reasoning.

Furthermore, while you have indeed identified some areas where the current
OAuth ecosystem could be improved, I reiterate that the current document,
defining a token format that is optional to use, is not the place to make
changes to how OAuth works.  I think you do everyone a disservice for
attempting to suggest that this document should do so.

Because there is so much based on a flawed foundation, I will not respond
inline to every point, but do see a few things where further clarification
would be useful.

On Thu, Apr 30, 2020 at 11:50:04AM +0200, Denis wrote:
> Hello Vittorio,
> 
> Your reply was amazingly fast. Responses are between the lines.
> 
> > Thanks Denis for the thorough commentary.
> >
> > /> The title of this spec./
> >
> > Fixed, thanks!
> >
> 
> > /> The client MUST NOT inspect the content of the access token/
> >
> >
> > This is really a sticky point. I really want to acknowledge your PoV 
> > on this, but at the same time I found this to be one of the biggest 
> > sources of issues
> > in the use of JWT for access tokens hence I feel we really need to 
> > give solid guidance here. Let me expand further on the reasoning 
> > behind it,
> > and perhaps we can get to language that satisfies both PoVs.
> >
> >
> > To me the key point is that clients should not write /code/ that 
> > inspects access tokens. Taking a dependency on the ability to do so is 
> > ignoring fundamental information
> > about the architecture and relationships between OAuth roles, and 
> > suggests an ability of the client to understand the semantic of the 
> > content that cannot be assumed
> > in the general case. I expanded on the details in my former reply to 
> > you on this topic, I would recommend referring to it.
> >
> > Clients violating this simple principle has been one of the most 
> > common sources of production issues I had to deal with in the past few 
> > years, and one of the hardest
> > to remediate given that clients are hard to update and sometimes the 
> > things they relied on were irremediably lost. This is why I am 
> > inclined to put in here strong language.
> >
> > That said: I have nothing against client developers examining a 
> > network trace and drawing conclusions based on the content of what 
> > they see. That doesn’t create any hard
> > dependencies and has no implications in respect to changes in the 
> > solution behavior. However I am not sure how to phrase that in the 
> > specification, given that referring
> > to the client inevitably refers to its code. I am open to suggestions.
> >
> First of all, a "*MUST NOT* "should not be placed in a privacy 
> considerations section, but in the main body of the document.
> The goal of a privacy considerations section is to provide explanations, 
> but not to introduce additional requirements.

That's not actually a requirement.  In many cases it makes sense to avoid
putting normative requirements in the security and/or privacy
considerations sections, but it is very much a thing that is done in many
RFCs, and in some cases it is useful to do so.

> Then after, since this section is about privacy considerations, it is 
> important to refer to an ISO standard that has been published 9 years ago.

Is it?  I don't see much precedent for IETF documents referencing this ISO
standard.  If it's so important you'd think that we'd have been citing it
with regularity.  Since this will be the first or second time, I think you
need to provide some additional justification as to how the topics it
covers fit within the existing IETF BCPs for how we treat security and
privacy considerations before we conclude that it is the appropriate
reference.

> It is ISO 29100 (Information technology — Security techniques — Privacy 
> framework). Most of the ISO standards need to be bought.
> However, there are a few exceptions and this standard can be freely 
> downloaded from the ISO web site, if you accept some conditions,
> using this URL:
> 
> https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
> 
> ISO 29100, even if it is outdated on some aspects (it only deals with 
> two entities), identifies ten principles (See Table 3).
> 
> 1. Consent and choice
> 
> 2. Purpose legitimacy and specification
> 
> 3. Collection limitation
> 
> 4. Data minimization
> 
> 5. Use, retention and disclosure limitation
> 
> 6. Accuracy and quality
> 
> 7. Openness, transparency and notice
> 
> 8. Individual participation and access
> 
> 9. Accountability
> 
> 10. Information security
> 
> 11. 

Re: [OAUTH-WG] PAR - Guidance on the request URI structure needed?

[Benjamin Kaduk]

On Mon, Apr 27, 2020 at 12:58:09PM -0400, Justin Richer wrote:
> I agree that any URI could be used but that it MUST be understood by the AS 
> to be local to the AS (and not something that can be impersonated by an 
> attacker). I wouldn’t even go so far as RECOMMENDED, but it’s certainly an 
> option.

IIUC BCP 190 has similar thoughts on the matter...

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Structured management of working documents

[Benjamin Kaduk]

Hi Jared,

On Thu, Apr 23, 2020 at 09:55:21PM -0500, Jared Jennings wrote:
> Hi all,
> 
> I know I am super new to the list, so bare with me with my
> observations that I would like share with the group. Probably no one in the
> list knows me, but I am used to online forms, mailing lists and I been
> involved in various open source applications for many years. So, these
> comments do not come from someone that isn't used to mailing lists.

Thanks for being bold and sharing your insight!  It is not often that we
have the benefit of such a fresh perspective.

> With that said, I find it difficult to follow the different
> threads, revisions, suggestions, comments, and topics that we discuss. It
> also seems that the current format makes it very difficult for the
> maintainer of the document.
> 
> As a suggestions or question, is there a reason we are not using a platform
> designed for this type of work? Like Github, bitbucket, etc. A great

The main reason that we continue to involve the IETF mailing list is due to
a longstanding historical IETF requirement for having WG work gain
consensus on the mailing list and be submitted to the IETF datatracker.
The original reasons for this policy (which long predates me, to be clear)
seem twofold: to be as accessible as possible to all (email does not
require significant bandwidth, real-time access, or installing/using
proprietary software), and to ensure compliance with the IETF IPR regimen.
With respect to the latter point, the IETF mailing lists and
datatracker-managed documents are subject to the "Note Well" policies of
BCPs 78 and 79, and the procedures for making other tools subject to the
same requirements are less well-established.

> example is the link that Brian shared. I can see exactly what is going on
> and I could even propose my own patch, which saves the editor loads of work.
> https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/3/attempt-to-tweak-the-wording-in-jar-so/diff

The above notwithstanding, the IETF has recently approved a pair of
documents that describe procedures for how a WG can choose to use github in
the course of their work.  (They are not RFCs yet, but are with the RFC
Editor in preparation as RFCs; they're linked from
https://datatracker.ietf.org/wg/git/documents/ .)  These procedures focus
on github because it's popular, but aren't intended to limit WGs to just
github as an available external tool; the procedures in question could no
doubt be modified to apply to other tools as well, if there is WG consensus
to do so.

Hope this helps,

Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth GREASE

[Benjamin Kaduk]

On Thu, Apr 23, 2020 at 04:52:49PM +, Mike Jones wrote:
> 
> I’d personally point out these non-compliant behaviors to the vendors and ask 
> them to fix them.  Their non-compliance makes it harder for clients to 
> interoperate with them, hurting both.  Name names, if that’s what it takes.

My understanding is that David Benjamin (author of TLS GREASE) put a lot of
time into tracking down and persuading vendors of broken implementations to
fix their stuff before GREASE itself could even be widely deployed without
a fallback.  GREASE is the result of wanting to never have to do that again
:)

So yes, someone should start tracking these people down, and I see a pretty
decent case for writing down something about OAuth GREASE as well.

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Benjamin Kaduk]

Just on the xml2rfc bits...

On Wed, Apr 22, 2020 at 07:26:40AM +, Vittorio Bertocci wrote:
> 
> > Link to section 4.1.2 of SCIM Core is actually linking to section 4.1.2 of 
> > this doc.
> Oh wow. That’s a feature of XML2RFC,… my source simply says by section 4.1.2 
> of SCIM Core  in a  block, and the processor interpret it as an internal 
> link. I’ll need to dig on how to prevent that from happening for this 
> instance. Good catch!

The short form is "you can't".

You're using the "v2" XML format for xml2rfc, which produces as various
output formats text, pdf, and "htmlized" output.  The "htmlized" output is
called that and not "html" because it's the result of taking the text
output and running a script to turn common constructions in I-Ds and RFCs
into hopefully-useful HTML formatting.  In this case, "Section N" outside
of "Section N of [bracketed-reference]" is assumed to be "Section N of the
current document", and that's all that the htmlization script is going to
give you, since it's not working with the semantic richness of the XML
source.

We do, however, as of fairly recently have a "v3" XML format, which is
capable of producing native HTML output that includes SVG figures and the
other exciting features of "v3 XML".  For an example, see
https://www.ietf.org/id/draft-ietf-tsvwg-datagram-plpmtud-19.html .

I personally haven't done any v2-to-v3 conversions yet (too busy reading to
have time to do much writing), but the FAQ entry for doing so is at
https://www.rfc-editor.org/materials/FAQ-xml2rfcv3.html#name-how-do-i-convert-my-xml-fil
.

Hope that helps,

Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Benjamin Kaduk]

Hi Denis,

I am going to top-post because the quoting in this thread has become pretty
mangled.

First off, thank you for calling out the text in the document about
scenarios where "the authorization server and resource server are not
co-located, are not run by the same entity, or are otherwise separated by
some boundary"; this does indeed present some consequences for the privacy
considerations of the protocol that will need to be addressed in some
manner, though not necessarily the one that you envision.  I will try to
remember to check for this point when the document progresses to IESG
Evaluation.

You outline some interesting protocol proposals, such as letting the client
choose the token profile type, mandating (in at least some cases)
visibility into the token contents for the client, and letting the client
add additional token parameters in its request, but it seems pretty clear
to me that while these would make for an interesting protocol, that
protocol would fundamentally not be OAuth 2.0.  As such, it doesn't seem
appropriate to attempt to require them as part of this specific document.

I would also note that framing things as a contrast between "privacy by
design" and "spy by design" seems designed to evoke an emotional reaction,
and as such are actively harmful to rational technical debate.  I implore
you to focus on the facts of what data flows where and which aspects of
such flows are desirable and undesirable in the various situations under
consideration.

Finally, I'll note that though I am mostly just an observer here and not an
implementor, it's my sense that OAuth 2.0 as currently deployed involves a
relatively large number of RSes speaking to a comparable or smaller number of
ASes, and that it is common for AS implementations to have significant
amounts of logic dedicated to knowing the capabilities of the RSes they
serve.  Many of your comments do not seem consistent with this worldview,
and I invite the other WG participants to clarify if my understanding is
incorrect.

Thanks,

Ben

On Fri, Apr 10, 2020 at 11:07:35AM +0200, Denis wrote:
> Hi Vittorio,
> 
> Thank you for your fast response.
> 
> You wrote:
> 
> "/It doesn’t look very likely that an RS would simply accept tokens
> from an AS without some out of band negotiatio/n, "
> 
> and also:
> 
> "/As far the client is concerned, the RS and the AS might switch
> their agreement/"
> 
> With such sentences, it seems that you mandate a direct negotiation 
> between the AS and the RS which, by implication,
> means that the AS and the RS must know each other, which is exactly what 
> I want to avoid. Such some out of band negotiation
> can simply be done by publishing which AT formats the AS is able to 
> generate and which AT formats the RS is able to accept.
> An AS can publish metadata relevant to the JWT access tokens it issues 
> and a RS can do the same.
> 
> In this way, the client could consult both published lists and choose 
> which common format, if any, would be appropriate.
> This means that the client should be able in its AT request to specify 
> the format of the AT, thus avoiding any direct some
> out of band negotiation between the AS and the RS.
> 
> You continue saying:
> 
> " /nor it seems very likely that an AS would issue tokens for
> resources it doesn’t know/".
> 
> This is where we have a major difference in our points of views. The 
> number of AS is likely to be several order of magnitudes higher
> compared to the number of RS. Every time a RS is being established, it 
> should not have to make itself known to any AS.
> 
> This is why I wrote:
> 
> /"a key point is that an AS and a RS DO NOT necessarily need to know
> each other. *The RS only needs to trust the AS*/*.*/(full stop)"/
> 
> You are assuming that an AS and a RS necessarily need to know each other.
> 
> You wrote:
> 
> "/The scenario in which a token issuer isn’t aware of where the
> client will spend the corresponding token is important,
> but it is more the province of SSI than mainstream OAuth2 usage today"./
> 
> Today, as soon as an AT is targeted, the AS will be aware where the 
> client is likely to spend the AT. The reality is that the scenario
> in which a token issuer will not be aware of where the client will spend 
> the corresponding token is today completely out of the scope
> of OAuth2 usages (unfortunately, it is not a matter of mainstream or not).
> 
> For that reason, if the spec. continues to prevent to implement "Privacy 
> by design" architectures and worse, mandates "Spy by design"
> architectures, this should be clearly advertised in the Privacy 
> Considerations section.
> 
> You recommend to specify the split AT structure I suggest in its own 
> spec rather than in an interop profile for the general AT case.
> The current title of the document is: "JSON Web Token (JWT) Profile for 
> OAuth 2.0 Access Tokens". The content of the document
> is much more than what the title 

Re: [OAUTH-WG] draft-ietf-oauth-dpop-00 comments

[Benjamin Kaduk]

On Tue, Apr 07, 2020 at 03:31:09PM -0600, Brian Campbell wrote:
> One of the primary motivations for the proof-of-possession mechanism of
> DPoP being at the application layer was to hopefully enable implementation
> and deployment by regular application developers. A lesson learned from the
> difficulties and lack of adoption around Token Binding was that access to
> TLS exporters is non-existent or prohibitively cumbersome in many
> development environments. Browsers, for example, don't expose any such API
> to javascript. And that's a non-starter here.
> 
> Are there other practical ways to include a server contribution that have
> been overlooked?

the main thing that comes to mind is (basically) an explicti nonce, which
costs an extra round trip unless you get clever.

In particular, "get clever" can be something that amortizes a single extra
round trip across *all* interactions with that server, akin to how ACME
requires a fresh nonce (and signature) for each request (RFC 8555).

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-dpop-00 comments

[Benjamin Kaduk]

On Mon, Apr 06, 2020 at 12:05:28PM -0600, Brian Campbell wrote:
> Hi Mike,
> 
> Thanks for your interest in the work and review of the draft. As one of the
> too-many authors on the document, I attempt to answer questions and respond
> to comments inline below. Though I admit to not having necessarily adequate
> answers to everything at the ready. And also apologize for the slow
> response, which is somewhat related to not having necessarily adequate
> answers.
> 
> On Wed, Apr 1, 2020 at 11:15 AM Peck, Michael A  wrote:
> 
> > Hi,
> >
> > Glad to see DPoP moving forward as a working group item.
> > I have a couple of comments on the current draft:
> >
> > 1.
> > I recommend expanding the description of the threat model.
> > It's not entirely clear to me what threats DPoP is expected to address,
> > which makes it hard to evaluate whether DPoP meets its objectives.
> >
> 
> Yeah, there's definitely some room for improvement in this area. And you
> are not the first to note the need. Complicating matters somewhat, however,
> is that there's some disparity of opinions about the specifics of the
> threat model and objectives. Despite that I do plan to work on trying to
> expand and clarify the threat model, objectives, expected applicability,
> etc. in the next revision of the draft.
> 
> 
> > Section 2 states that the main objective is to prevent an adversary who
> > set up a counterfeit AS or RS from replaying a received refresh token or
> > access token at another server. Would it be possible to expand upon the
> > description of this threat and how it may occur?
> >
> 
> I'm hoping perhaps Daniel can help expand on this as the current text
> originated with him. Although I think separate consideration of AS and RS
> would be helpful because I think the factors involved in counterfeiting or
> confusing them are pretty different.
> 
> 
> > Are there other situations where an adversary may be able to capture a
> > refresh token or access token that should be mentioned as objectives to
> > address - e.g. malicious / third-party JavaScript code?
> >
> 
> Probably, yeah. Although any JavaScript code that could exfiltrate tokens
> could also likely be used to drive an attack directly. And that possibility
> can devolve into questioning the value of key-binding or preventing
> exfiltration at all (similarish criticisms have been levied at the HttpOnly
> cookie flag and HTTP Token Binding). I'm sympathetic to that line of
> reasoning to the point of finding it somewhat depressing. But I try and
> avoid falling into full-blown XSS nihilism and (maybe stubbornly/naively)
> still think there's some value in key constraining tokens. And, to your
> point, a more detailed look at potential leakage/theft situations would be
> useful.

One point to consider is whether the exfiltrated material can be widely
replicated to turn into a distributed attack.

> 
> 
> >
> > Presumably the counterfeit AS or RS will not have the same hostname (e.g.
> > with an illegitimately issued server certificate) as the legitimate server,
> > as otherwise DPoP wouldn’t provide protection.
> 
> 
> Yeah, an assumption (that admittedly should be made more explicit) is that
> TLS/HTTPS with server authentication isn't broken.
> 
> 
> 
> > Why would the client send the refresh token to the wrong AS?
> >
> 
>  Daniel maybe has some more ideas here but social engineering is the one
> reason that I keep hearing. It's not super compelling but is a reason.
> 
> 
> 
> > For resource servers, why wouldn’t an access token audience restriction
> > suffice? Is the concern that the access token might not contain an audience
> > restriction, or might contain multiple audiences? (If the concern is that
> > the resource server wouldn’t check the audience, I’d have a similar concern
> > that it wouldn’t check a DPoP proof.)
> >
> 
> Audience restriction can work to prevent RS to RS token usage. But in
> practice it has turned out that properly getting and using audience
> restricted ATs is prohibitively cumbersome for many deployments.
> 
> 
> >
> > 2.
> > DPoP currently does not provide any guarantees that the DPoP signature was
> > freshly generated, as there is no nonce from the server incorporated into
> > the signature.
> > I assume there is no practical means for the server to send a nonce to the
> > client to use with each request that wouldn't over-complicate DPoP.
> >
> 
> Keeping it relatively simple has definitely been a goal. And yeah, I can't
> think of a practical way to do something like that without big changes. If
> big changes are needed, the whole approach might be in question and
> something like Neil's key agreement scheme that I mentioned in the last
> interim
> https://datatracker.ietf.org/meeting/interim-2020-oauth-02/session/oauth
> could well be a better overall approach to consider.
> 
> 
> > I also don't see any guidance in the draft about lifetime/rotation of each
> > DPoP key or whether the same key can be used with multiple 

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Benjamin Kaduk]

On Tue, Mar 31, 2020 at 09:33:35PM +, Vittorio Bertocci wrote:
> 
> > I’ve already replied to the other thread, but I’ll note that “different 
> > strengths, different lifecycles” don’t matter much if the RS will accept 
> > both types of tokens, signed with either key.
> point taken. I applied the changes discussed on the  other thread.
> 
> >As noted, I’d support making them REQUIRED. Failing that, RECOMMENDED.
> Promoted to RECOMMENDED

I'd also prefer REQUIRED, and thanks for already moving to RECOMMENDED
(which I was going to suggest as an alternative).

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

Hi Torsten,

Sorry for the delayed response; it seems this got buried beneath some other
things.  Thanks to everyone else for contributing, and I think there's just
one point left that needs a response (inline)...

On Mon, Mar 02, 2020 at 03:19:11PM +0100, Torsten Lodderstedt wrote:
> Hi Ben,
> 
> >> 
> >>> 
> >>> 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?
> 
> Sure. 
> 
> 1) Let’s assume a client obtains access token “123456789”, which obviously is 
> a handle the RS needs to resolve using Introspection. 
> 2) The RS calls the introspection endpoint, the AS looks up the access token 
> data and responds with a JWT formatted introspection response (including a 
> fresh jti “abc234567”). 
> 3) The RS stores the jti in its replay cache (long with the tokens max 
> lifetime)
> 
> 4) The client calls the RS again using the same token “123456789”
> 5) The RS calls the introspection endpoint again, the AS looks up the access 
> token data and responds with a JWT formatted introspection response 
> (including a fresh jti “abc8912345”).
> 6) The RS compares the jti with its replay cache, no hit - it thinks all is 
> good and performs the requested transaction. 
> 
> But it just accepted the same token for the 2nd time. 
> 
> If the AS would have created JWT formatted introspection responses with the 
> same jti, the RS would had a cache hit in step (6) and refused the request. 
> 
> > 
> >> 
> >> “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?
> 
> Sorry I don't understand. Can you please elaborate?

I was trying to combine two thoughts here but didn't provide a good
connection.  Consider the test from RFC 7519, "The "jti" (JWT ID) claim
provides a unique identifier for the JWT."  If we are to claim that the JWT
introspection response is a JWT, then the "jti" value contained therein is
supposed to pose a "unique identifier for the JWT [introspection
response]".  But if it is clearly specified that the contents of the
introspection response (a JWT) are to change from having [a bunch of stuff]
to [mostly just "active":false], I can't come up with an interpretation
in which both [a bunch of stuff] and [mostly just "active":false] can be
considered "the same JWT".  In a more general sense, I would treat "the
JWT" as the actual encoded artifact with header, claim set, and signature,
and under that assumption it's clear that any change in the encoded
artifact would be a different "JWT".

IIUC this point is now moot based on the direction we seem to be going in,
but hopefully that helps clarify my thinking.

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth WG Virtual Meeting During IETF 107?

[Benjamin Kaduk]

On Fri, Mar 13, 2020 at 10:37:50AM -0700, William Denniss wrote:
> Now that the IETF 107 virtual meeting agenda was posted
> ,
> and only includes BOFs and new WGs, should we schedule our own virtual
> meeting for the same week?

I believe that virtual interim requests will be denied for that week, but
there should be plenty of flexibility to schedule one or more in the
following weeks.

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

[Benjamin Kaduk]

Hi Torsten,

Sorry for the delayed response, but since I was explicitly listed in the
"To:" field I expect the response is still of interest.
On Wed, Mar 04, 2020 at 05:19:13PM +0100, Torsten Lodderstedt wrote:
> Hi all, 
> 
> based on the recent feedback, Vladimir and I propose the following changes to 
> draft-ietf-oauth-jwt-introspection-response: 
> 
> - the token data are encapsulated in a container element “_token_data”
> - beyond this, the top-level container only contains meta data pertinent to 
> the JWT representing the signed (encrypted) introspection response
> - we need to add text to the spec to point out that replay detection must be 
> based on the jti in the “_token_data” container not the top level claim

I think this sort of thing will resolve the fundamental issues quite well.
(I want to say I had listed it as a potential option some months ago, but
don't have the time to go look in the archives and check.)

I see there's still some discussion ongoing about specifics, which is fine;
I expect we will still end up in a good place.

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

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 
> >  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. 
> 
&g

[OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker]

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/



--
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?

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.

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?


--
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 b

Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

Hi Nat,

Now it is my turn to apologize for taking a long time.

I think I see the general direction these changes are going in, and it's a
reasonable approach to the unfortunate situation we find ourselves in with
respect to JWT claims vs. OAuth parameters.  In effect, what we're doing is
making a "profile" (for lack of a better term) of JWT, that leverages the
mechanisms and algorithms of JWT but uses a different registry for
interpreting the claims in the token (that is, OAuth Parameters vs. JWT
Claims).  We can tell that this "profile" of JWT is being used because of
the context in which the JWT is transferred/received: if it's the "request"
parameter, that's part of the definition of the OAuth Parameter, and if
it's the result of dereferencing a "request_uri", the
application/oauth.authz.req+jwt media-type clearly indicates how the
contents should be interpreted.

However, the changes in the -20 do not give the reader much of any hint as
to this being what's expected to happen, and that stock RFC 7519 JWT is
*not* what's in use.  So I'd request that we take a close look at how the
document uses "JWT" vs. "JWT encoding" (etc.); add an explicit statement
that while the JWT encoding is in use, the contents are to be interpreted
by interpreting the JWT claims as OAuth Parameters (and not as per the IANA
registry of JWT claims); and add some discussion (similar to the above)
about how the application context makes it unambiguous whether the
JWT-encoded claims are standard JWT claims or OAuth Parmaters as per this
document.

With respect to my second ("discuss discuss") point, Nat and I did have a
discussion in-person and I accept that there may be some scenarios in which
skipping the authorization dialogue is appropriate, so the example can
remain.


Moving on from my Discuss position, I do get the sense from the ongoing
discussion on the list that there's not clear agreement about the current
formulation that requires all parameters (but "request" and "request_uri")
to be in the JAR, especially with respect to "client_id" that might be
needed to unpack the JAR in some cases!  So I'm not sure whether the WG
wants to bring the document back to the WG to iron out those issues before
it returns to the IESG.  I'm a little reluctant to switch my position to
"No Objection" until we have a clearer picture of what the WG wants to do
on this front -- in my understanding, we can't really publish the document
without at least some solution ("client_id") for the encrypted-request
key-lookup case.

Thanks,

Ben


On Sun, Oct 27, 2019 at 10:12:50AM +0100, Nat Sakimura wrote:
> Hi
> 
> Took a long time but finally all the changes needed to resolve the DISCUSS
> comments are (hopefully) applied as -20.
> 
> There is one change that impacts the process: the draft now has IANA
> request so it needs to be referred back to IANA.
> 
> The IETF datatracker status page for this draft is:
> datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
> 
> Best,
> 
> Nat Sakimura
> 
> 2019年7月3日(水) 4:21 Benjamin Kaduk via Datatracker :
> 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-oauth-jwsreq-19: 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-jwsreq/
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > This is a "discuss discuss" -- it's an important question and I'd like
> > to talk about it, but it's not clear that any change to the document
> > will be needed.
> >
> > Once this (and some of the more substantive items in the Comment
> > section) is resolved, I'd be happy to ballot Yes.
> >
> > The introduction notes as an advantage of JWT that:
> >
> >(d)  (collection minimization) The request can be signed by a third
> > party attesting that the authorization request is compliant with
> > a certain policy.  For example, a request can be pre-examined by
> > a third party that all the personal data requested is strictly
> > necessary to perform the process that the end-user asked for,
> > and statically si

Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

[Benjamin Kaduk]

;> Is that the only paramater that people have a issue with as oposed to a
> >> nice to have?
> >> 
> >> Would allowing the AS to not ignore the clientID as a query paramater as
> >> long as it matches the one inside the JAR, basicly the same as Connect
> >> request object but for just the one paramater make life easier for the
> >> servers?
> >> 
> >> I am not promising a change but gathering info before proposing something.
> >> 
> >> John B.
> >> 
> >> 
> >> On 1/16/2020 1:53 AM, Benjamin Kaduk wrote:
> >>> On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov wrote:
> >>>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
> >>>>> Well, embedding a client_id claim in the JWE header in order to
> >>>>> achieve "request parameters outside the request object should not be
> >>>>> referred to" is like "putting the cart before the horse". Why do we
> >>>>> have to avoid using the traditional client_id request parameter so
> >>>>> stubbornly?
> >>>>> 
> >>>>> The last paragraph of Section 3.2.1
> >>>>> <https://tools.ietf.org/html/rfc6749#section-3.2.1> of RFC 6749 says
> >>>>> as follows.
> >>>>> 
> >>>>>   /A client MAY use the "client_id" request parameter to identify
> >>>>>   itself when sending requests to the token endpoint.  In the
> >>>>>   "authorization_code" "grant_type" request to the token endpoint,
> >>>>>   *an unauthenticated client MUST send its "client_id" to prevent
> >>>>>   itself from inadvertently accepting a code intended for a client
> >>>>>   with a different "client_id".*  This protects the client from
> >>>>>   substitution of the authentication code.  (It provides no
> >>>>>   additional security for the protected resource.)/
> >>>>> 
> >>>>> 
> >>>>> If the same reasoning applies, a client_id must always be sent with
> >>>>> request / request_uri because client authentication is not performed
> >>>>> at the authorization endpoint. In other words, */an unauthenticated
> >>>>> client (every client is unauthenticated at the authorization endpoint)
> >>>>> MUST send its "client_id" to prevent itself from inadvertently
> >>>>> accepting a request object for a client with a different "client_id"./*
> >>>>> 
> >>>> Identifying the client in JAR request_uri requests can be really useful
> >>>> so that an AS which requires request_uri registration to prevent DDoS
> >>>> attacks and other checks can do those without having to index all
> >>>> request_uris individually. I mentioned this before.
> >>>> 
> >>>> I really wonder what the reasoning of the IESG reviewers was to insist
> >>>> on no params outside the JAR JWT / request_uri.
> >>>> 
> >>>> I'm beginning to realise this step of the review process isn't
> >>>> particularly transparent to WG members.
> >>> Could you expand on that a bit more?  My understanding is that the IESG
> >>> ballot mail gets copied to the WG precisely so that there is transparency,
> >>> e.g., the thread starting at
> >>> https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI
> >>> Which admittely is from almost three years ago, but that's the earliest
> >>> that I found that could be seen as the source of this behavior.
> >>> 
> >>> -Ben
> >>> 
> >>> P.S. some other discussion at
> >>> https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8 
> >>> and
> >>> https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY 
> >>> and
> >>> so on.
> >>> 
> >>> ___
> >>> 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
> 

> ___
> 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

Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

[Benjamin Kaduk]

Definitely; thanks for raising that explicitly.

-Ben

On Fri, Jan 17, 2020 at 04:34:10PM +, Richard Backman, Annabelle wrote:
> We should not be prescriptive about how the AS recognizes request URIs from 
> itself. Trusted authority or custom URI scheme are fine as examples, but 
> ultimately this is an internal implementation of the AS. It could just as 
> easily be using data URIs containing a symmetrically encrypted database 
> record ID.
> 
> > On Jan 16, 2020, at 8:00 PM, Benjamin Kaduk  wrote:
> > 
> > On Thu, Jan 16, 2020 at 04:31:30PM +, Neil Madden wrote:
> >> The mitigations of 10.4.1 are related, but the section heading is about 
> >> (D)DoS attacks. I think this heading needs to be reworded to apply to SSRF 
> >> attacks too or else add another section with similar mitigations. 
> >> 
> >> Mitigation (a) is a bit vague as to what an "unexpected location" is. 
> >> Perhaps specific wording that it should be a URI that has been 
> >> pre-registered for the client (and validated at that time) or is otherwise 
> >> known to be safe (e.g., is a URI scheme controlled by the AS itself as 
> >> with PAR).
> > 
> > pedantic nit: "URI scheme" is probably not what we want, as the authority
> > component of the URI (per RFC 3986) seems more likely to match "controlled
> > by the AS itself"
> > 
> > -Ben
> > 
> >> In addition for this to be effective the AS should not follow redirects 
> >> when fetching the URI. It's not clear to me whether that is implied by 
> >> "not perform recursive GET" so it may be worth explicitly spelling that 
> >> out.
> >> 
> > 
> > ___
> > 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

Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

[Benjamin Kaduk]

On Thu, Jan 16, 2020 at 04:31:30PM +, Neil Madden wrote:
> The mitigations of 10.4.1 are related, but the section heading is about 
> (D)DoS attacks. I think this heading needs to be reworded to apply to SSRF 
> attacks too or else add another section with similar mitigations. 
> 
> Mitigation (a) is a bit vague as to what an "unexpected location" is. Perhaps 
> specific wording that it should be a URI that has been pre-registered for the 
> client (and validated at that time) or is otherwise known to be safe (e.g., 
> is a URI scheme controlled by the AS itself as with PAR).

pedantic nit: "URI scheme" is probably not what we want, as the authority
component of the URI (per RFC 3986) seems more likely to match "controlled
by the AS itself"

-Ben

> In addition for this to be effective the AS should not follow redirects when 
> fetching the URI. It's not clear to me whether that is implied by "not 
> perform recursive GET" so it may be worth explicitly spelling that out.
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

[Benjamin Kaduk]

On Fri, Jan 17, 2020 at 12:47:45AM +0900, Nat Sakimura wrote:
> Right. We could add a security consideration like that, though the
> mitigation probably is pretty much the same as what is stated in 10.4.1:
> 
> the server should (a) check that
>the value of "request_uri" parameter does not point to an unexpected
>location, (b) check the content type of the response is "application/
>oauth.authz.req+jwt" (c) implement a time-out for obtaining the
>content of "request_uri", and (d) not perform recursive GET on the
>"request_uri".
> 
> If not, please let me know so that we can add that as the mitigation as
> well.

We should probably make sure that we talk about the risks and scope of
potential problems if these checks are not correctly performed.  (I forget
whether we talk about them already or not.)

> Existing OIDC deployment cannot make use of application/oauth.authz.req+jwt
> but it has to validate that content is a valid request object anyways and
> if it is malformed, it MUST stop the processing and return an error
> invalid_request_uri. So, unlike in the case of Capital One's SSRF, the
> content of the request_uri will not be exposed. The main downside is
> therefore as depicted in the current draft, consumption of the network and
> processing power of the AS, and the unwanted access load to the servers
> serving the URL pointed by request_uri. The above-quoted mitigations were
> introduced to address these issues.

Understood; thanks.

-Ben

> 
> 
> 
> On Thu, Jan 16, 2020 at 11:33 PM Benjamin Kaduk  wrote:
> 
> > It is not too late to add to the security considerations.
> >
> > It seems that the new application/oauth.authz.req+jwt media-type is helpful
> > in this regard, in that if an AS can require that content-type from
> > dereferencing the request_uri, then seeing anything else indicates that the
> > request was bogus (or an attack).  I guess existing OIDC deployments aren't
> > exactly in a position to do that, though.
> >
> > -Ben
> >
> > On Thu, Jan 16, 2020 at 08:34:06AM +, Neil Madden wrote:
> > > Is it too late to add it to the security considerations for JAR?
> > >
> > > — Neil
> > >
> > > > On 16 Jan 2020, at 08:15, Dominick Baier 
> > wrote:
> > > >
> > > > 
> > > > Agreed - that’s why we disabled request_uri by default and added
> > extensibility points to implement validation.
> > > >
> > > > I thought it is odd that this was not mentioned in the typical
> > “security considerations” in the OIDC spec..
> > > >
> > > > ———
> > > > Dominick Baier
> > > >
> > > >> On 16. January 2020 at 08:07:44, Neil Madden (
> > neil.mad...@forgerock.com) wrote:
> > > >>
> > > >> If the AS can’t validate the request_uri it may also open itself up
> > to SSRF attacks where a malicious client uses the request_uri to
> > probe/attack resources inside the AS’s private network. This was a crucial
> > part of the recent Capital One breach for example [1].  ForgeRock currently
> > requires strict validation of request_uris against a client-specific
> > whitelist for exactly this reason.
> > > >>
> > > >> NB some clients might legitimately be on that private network (eg
> > microservices) so changing to a global whitelist for all clients is
> > undesirable.
> > > >>
> > > >> [1]: https://ejj.io/blog/capital-one
> > > >>
> > > >> — Neil
> > > >>
> > > >>> On 15 Jan 2020, at 21:02, Vladimir Dzhuvinov <
> > vladi...@connect2id.com> wrote:
> > > >>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
> > > >>>> Well, embedding a client_id claim in the JWE header in order to
> > achieve "request parameters outside the request object should not be
> > referred to" is like "putting the cart before the horse". Why do we have to
> > avoid using the traditional client_id request parameter so stubbornly?
> > > >>>>
> > > >>>> The last paragraph of Section 3.2.1 of RFC 6749 says as follows.
> > > >>>>
> > > >>>> A client MAY use the "client_id" request parameter to identify
> > itself when sending requests to the token endpoint.  In the
> > "authorization_code" "grant_type" request to the token endpoint, an
> > unauthenticated client MUST send its "client_id" to prevent itself from
> > inadvert

Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

[Benjamin Kaduk]

It is not too late to add to the security considerations.

It seems that the new application/oauth.authz.req+jwt media-type is helpful
in this regard, in that if an AS can require that content-type from
dereferencing the request_uri, then seeing anything else indicates that the
request was bogus (or an attack).  I guess existing OIDC deployments aren't
exactly in a position to do that, though.

-Ben

On Thu, Jan 16, 2020 at 08:34:06AM +, Neil Madden wrote:
> Is it too late to add it to the security considerations for JAR? 
> 
> — Neil
> 
> > On 16 Jan 2020, at 08:15, Dominick Baier  wrote:
> > 
> > 
> > Agreed - that’s why we disabled request_uri by default and added 
> > extensibility points to implement validation.
> > 
> > I thought it is odd that this was not mentioned in the typical “security 
> > considerations” in the OIDC spec..
> > 
> > ———
> > Dominick Baier
> > 
> >> On 16. January 2020 at 08:07:44, Neil Madden (neil.mad...@forgerock.com) 
> >> wrote:
> >> 
> >> If the AS can’t validate the request_uri it may also open itself up to 
> >> SSRF attacks where a malicious client uses the request_uri to probe/attack 
> >> resources inside the AS’s private network. This was a crucial part of the 
> >> recent Capital One breach for example [1].  ForgeRock currently requires 
> >> strict validation of request_uris against a client-specific whitelist for 
> >> exactly this reason. 
> >> 
> >> NB some clients might legitimately be on that private network (eg 
> >> microservices) so changing to a global whitelist for all clients is 
> >> undesirable. 
> >> 
> >> [1]: https://ejj.io/blog/capital-one
> >> 
> >> — Neil
> >> 
> >>> On 15 Jan 2020, at 21:02, Vladimir Dzhuvinov  
> >>> wrote:
> >>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
>  Well, embedding a client_id claim in the JWE header in order to achieve 
>  "request parameters outside the request object should not be referred 
>  to" is like "putting the cart before the horse". Why do we have to avoid 
>  using the traditional client_id request parameter so stubbornly?
>  
>  The last paragraph of Section 3.2.1 of RFC 6749 says as follows.
>  
>  A client MAY use the "client_id" request parameter to identify itself 
>  when sending requests to the token endpoint.  In the 
>  "authorization_code" "grant_type" request to the token endpoint, an 
>  unauthenticated client MUST send its "client_id" to prevent itself from 
>  inadvertently accepting a code intended for a client with a different 
>  "client_id".  This protects the client from substitution of the 
>  authentication code.  (It provides no additional security for the 
>  protected resource.)
>  
>  If the same reasoning applies, a client_id must always be sent with 
>  request / request_uri because client authentication is not performed at 
>  the authorization endpoint. In other words, an unauthenticated client 
>  (every client is unauthenticated at the authorization endpoint) MUST 
>  send its "client_id" to prevent itself from inadvertently accepting a 
>  request object for a client with a different "client_id".
>  
> >>> Identifying the client in JAR request_uri requests can be really useful 
> >>> so that an AS which requires request_uri registration to prevent DDoS 
> >>> attacks and other checks can do those without having to index all 
> >>> request_uris individually. I mentioned this before.
> >>> 
> >>> I really wonder what the reasoning of the IESG reviewers was to insist on 
> >>> no params outside the JAR JWT / request_uri.
> >>> 
> >>> I'm beginning to realise this step of the review process isn't 
> >>> particularly transparent to WG members.
> >>> 
> >>> Vladimir
> >>> 
> >>> 
> >>> 
>  Best Regards,
>  Taka
>  
>  
>  
>  On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov 
>   wrote:
> > John, thanks, much appreciated!
> > 
> >> On 11/01/2020 21:36, John Bradley wrote:
> >> Yes JAR is not prohibiting paramater replication in the header. 
> >> 
> >> I will see if i can add something in final edits to call that out.
> >> 
> >> John B.
> >> 
> >>> On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:
> >>> Thanks Mike for the rfc7519 section-5.3 pointer. Can this parameter 
> >>> replication be used for client_id or the client_id ass "iss" even 
> >>> though it isn't explicitly mentioned in the JAR spec?
> >>> 
>  On 11/01/2020 02:58, John Bradley wrote:
>  Right we just don't say to put the iss there in OIDC if it's 
>  symetricly encrypted.
> >>> OIDC doesn't have the symmetric key selection issue, I suppose that 
> >>> why the possibility to replicate params to the JWE header isn't 
> >>> mentioned at all. OIDC requires the top-level query params to 
> >>> represent a valid OAuth 2.0 request, and there client_id is required. 
> >>> If the client_id is 

Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

[Benjamin Kaduk]

On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov wrote:
> 
> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
> > Well, embedding a client_id claim in the JWE header in order to
> > achieve "request parameters outside the request object should not be
> > referred to" is like "putting the cart before the horse". Why do we
> > have to avoid using the traditional client_id request parameter so
> > stubbornly?
> >
> > The last paragraph of Section 3.2.1
> >  of RFC 6749 says
> > as follows.
> >
> > /A client MAY use the "client_id" request parameter to identify
> > itself when sending requests to the token endpoint.  In the
> > "authorization_code" "grant_type" request to the token endpoint,
> > *an unauthenticated client MUST send its "client_id" to prevent
> > itself from inadvertently accepting a code intended for a client
> > with a different "client_id".*  This protects the client from
> > substitution of the authentication code.  (It provides no
> > additional security for the protected resource.)/
> >
> >
> > If the same reasoning applies, a client_id must always be sent with
> > request / request_uri because client authentication is not performed
> > at the authorization endpoint. In other words, */an unauthenticated
> > client (every client is unauthenticated at the authorization endpoint)
> > MUST send its "client_id" to prevent itself from inadvertently
> > accepting a request object for a client with a different "client_id"./*
> >
> Identifying the client in JAR request_uri requests can be really useful
> so that an AS which requires request_uri registration to prevent DDoS
> attacks and other checks can do those without having to index all
> request_uris individually. I mentioned this before.
> 
> I really wonder what the reasoning of the IESG reviewers was to insist
> on no params outside the JAR JWT / request_uri.
> 
> I'm beginning to realise this step of the review process isn't
> particularly transparent to WG members.

Could you expand on that a bit more?  My understanding is that the IESG
ballot mail gets copied to the WG precisely so that there is transparency,
e.g., the thread starting at
https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI
Which admittely is from almost three years ago, but that's the earliest
that I found that could be seen as the source of this behavior.

-Ben

P.S. some other discussion at
https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8 and
https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY and
so on.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

[Benjamin Kaduk]

I'm only the irresponsible AD here, but I expect that you would be welcome
(nay, encouraged!) to write up a clear explanation of why the current
(post-IESG) formulation is bad, what a better formulation should be, and
why.  This would presumably also include some justification for how the
better formulation remains secure (which can be somewhat challenging when
combining data sources that have differing levels of provenance).  The
strongest voice that drove the change at IESG evaluation (Ben C) is no longer
on the IESG, though IIRC the arguments resonated pretty well with me.

-Ben

On Wed, Jan 15, 2020 at 09:27:38PM +, Mike Jones wrote:
> I’m increasingly thinking that we should push back on the IESG and go back to 
> the semantics that the working group approved.  We can use the client_id 
> example with an encrypted request object to motivate the (Connect-compatible) 
> syntax and semantics.
> 
>-- Mike
> 
> From: Vladimir Dzhuvinov 
> Sent: Wednesday, January 15, 2020 1:03 PM
> To: Takahiko Kawasaki 
> Cc: John Bradley ; Mike Jones 
> ; IETF oauth WG 
> Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request 
> (JAR) vs OIDC request object
> 
> 
> 
> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
> Well, embedding a client_id claim in the JWE header in order to achieve 
> "request parameters outside the request object should not be referred to" is 
> like "putting the cart before the horse". Why do we have to avoid using the 
> traditional client_id request parameter so stubbornly?
> 
> The last paragraph of Section 
> 3.2.1 of RFC 6749 says as 
> follows.
> A client MAY use the "client_id" request parameter to identify itself when 
> sending requests to the token endpoint.  In the "authorization_code" 
> "grant_type" request to the token endpoint, an unauthenticated client MUST 
> send its "client_id" to prevent itself from inadvertently accepting a code 
> intended for a client with a different "client_id".  This protects the client 
> from substitution of the authentication code.  (It provides no additional 
> security for the protected resource.)
> 
> If the same reasoning applies, a client_id must always be sent with request / 
> request_uri because client authentication is not performed at the 
> authorization endpoint. In other words, an unauthenticated client (every 
> client is unauthenticated at the authorization endpoint) MUST send its 
> "client_id" to prevent itself from inadvertently accepting a request object 
> for a client with a different "client_id".
> 
> 
> Identifying the client in JAR request_uri requests can be really useful so 
> that an AS which requires request_uri registration to prevent DDoS attacks 
> and other checks can do those without having to index all request_uris 
> individually. I mentioned this before.
> 
> I really wonder what the reasoning of the IESG reviewers was to insist on no 
> params outside the JAR JWT / request_uri.
> 
> I'm beginning to realise this step of the review process isn't particularly 
> transparent to WG members.
> 
> Vladimir
> 
> 
> Best Regards,
> Taka
> 
> 
> 
> On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov 
> mailto:vladi...@connect2id.com>> wrote:
> 
> John, thanks, much appreciated!
> On 11/01/2020 21:36, John Bradley wrote:
> 
> Yes JAR is not prohibiting paramater replication in the header.
> 
> I will see if i can add something in final edits to call that out.
> 
> John B.
> On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:
> 
> Thanks Mike for the rfc7519 
> section-5.3 pointer. Can 
> this parameter replication be used for client_id or the client_id ass "iss" 
> even though it isn't explicitly mentioned in the JAR spec?
> On 11/01/2020 02:58, John Bradley wrote:
> Right we just don't say to put the iss there in OIDC if it's symetricly 
> encrypted.
> 
> OIDC doesn't have the symmetric key selection issue, I suppose that why the 
> possibility to replicate params to the JWE header isn't mentioned at all. 
> OIDC requires the top-level query params to represent a valid OAuth 2.0 
> request, and there client_id is required. If the client_id is present the 
> client registration together with any present client_secret can be retrieved.
> 
> I reread the JAR spec, this is the only place that mentions handling of 
> symmetric JWE.
> 
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2
> 
>(b)  Verifying that the symmetric key for the JWE encryption is the
> 
> correct one if the JWE is using symmetric encryption.
> 
> 
> 
> Vladimir
> 
> 
> 
> On Fri, Jan 10, 2020, 9:41 PM Mike Jones 
> mailto:michael.jo...@microsoft.com>> wrote:
> The technique of replicating JWT claims that need to be publicly visible in 
> an encrypted JWT in the header is defined at 
> https://tools.ietf.org/html/rfc7519#section-5.3.  (Thanks to Dick Hardt 

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR): signing

[Benjamin Kaduk]

On Tue, Jan 14, 2020 at 04:29:39PM -0500, George Aristy wrote:
> Hello everyone.
> 
> Is it possible to relax the requirement to sign the claims set if an
> authenticated encryption mode with prior shared secrets is used? Eg.
> https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-02. This would
> reduce the size of the request object substantially.

It seems fairly late in the publication process to make such a change,
since the properties provided by digital signature and AEAD tag are subtly
different, and the key-management lifecycle needed to provide secure
operation is different.

That said, off the top of my head, I don't know of anything that would
prevent this functionality from being specified as an extension to plain
JAR.

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

[Benjamin Kaduk]

On Mon, Jan 13, 2020 at 12:32:41PM -0500, Justin Richer wrote:
> To be clear, I’m not saying we suggest a particular form, and I agree that we 
> shouldn’t specify that “it’s a JWT” or something of that nature. But if we 
> call the result of PAR “thing X” and the target of request_uri “thing X” in 
> JAR, then we’re compatible without saying what “thing X” needs to be in all 
> cases. 
> 

That seems fair.  What properties would a given "thing X" need to have in
order to work, though -- uniqueness over a specific period of time?
Unpredictability?  More?

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: I-D Action: draft-ietf-oauth-access-token-jwt-03.txt

[Benjamin Kaduk]

On Tue, Dec 17, 2019 at 09:12:26PM +, Richard Backman, Annabelle wrote:
> > That's a pretty strong statement :)
> 
> One I should’ve clarified.  I don’t mean that the one-RS-per-AT model is not 
> used at all, just that it is not universal and comes with real, practical 
> tradeoffs that may not be appropriate for all use cases. Consequently, we 
> should not design fundamental specs that mandate its adoption.
> 
> 
> > …knowledge of that level isn't necessary.
> 
> Either the RS and AS have a shared understanding of that level, or the RS is 
> trusting the AS to decide what “AuthenticatedClient” means, and set it 
> accordingly. The latter requires that the RS only supports ASes that have a 
> shared (or substantially similar) understanding of what that level is, which 
> is unlikely outside of a closed system. In that case, there isn’t a lot of 
> value in providing a standard claim, as the closed system could just as 
> easily define a proprietary one.

Talk of the different potential levels of authentication calls to mind RFC
8485's "Vectors of Trust" idiom, though, IIUC, it would require some
adaptation to be useful here.

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Additional WGLC review of OAuth 2.0 Security Best Current Practice by an AAD developer

[Benjamin Kaduk]

On Thu, Nov 28, 2019 at 12:12:54AM +, Mike Jones wrote:
> Please also add these WGLC comments that a Microsoft Azure Active Directory 
> (AAD) developer asked me to convey:
> 
> 
>   1.  In 4.12, "Authorization servers MUST determine based on their risk 
> assessment whether to issue refresh tokens to a certain client [...]" I'm not 
> sure what this requirement requires in practice. AAD issues refresh_tokens to 
> all clients upon request and user consent and applies different lifetime 
> policies to different clients. We also routinely make risk assessments about 
> all manner of things. Does AAD thereby comply with this guideline? Reading 
> the whole paragraph, I think the paragraph is trying to encourage OAuth 
> clients which use a RT when the RT is returned but use auth codes when the RT 
> is not returned. That's fine, but the current text comes off as imposing a 
> vague requirement on authorization servers. Edits inline - "Authorization 
> servers MUST MAY dynamically determine based on their risk assessment whether 
> to issue refresh tokens to a certain client.  If the authorization server 
> decides not to issue refresh tokens, the client may SHOULD refresh access 
> tokens by utilizi
 ng other grant types, such as the authorization code grant type.  In such a 
case, the authorization server may utilize cookies and persistent grants to 
optimize the user experience."

FYI...

Using HTML bold/strikethrough doesn't work very well in the text/plain
portion, which is the only one displayed in the official archives:
https://mailarchive.ietf.org/arch/msg/oauth/Yzw0Mk4Ke3yyCH0Oo7MmatXA_tg

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC review of draft-ietf-oauth-security-topics-13

[Benjamin Kaduk]

Hi Pedram,

Thanks for confirming that the scenario is as I was trying to understand
it.  I don't think it's universal that all clients will give transitive
access from the user to the accessed resource, though it's certainly
common; the lack of exposition on that point is what I had been stumbling
on.

-Ben

On Tue, Nov 26, 2019 at 06:33:04PM +0100, Pedram Hosseyni wrote:
> Hi Ben,
> 
> The attacker uses the (honest) client shown in Figure 4 as a regular 
> user. For example, the client might provide access to a cloud storage 
> via its website, i.e., by using the clients' website, a user can access 
> her files stored at the resource server.
> 
> I'll try to clarify the attack with a simplified example.
> 
> Let's assume that the client supports two authorization servers 
> AS_honest and AS_attacker. Intuitively, if the attacker phishes an 
> access token created by AS_honest for an honest user (Alice), one would 
> expect that sender-constraining the access token (e.g., via mTLS) 
> prevents the attacker from using this access token.
> 
> The overall goal of the attacker is to use the sender-constrained access 
> token (which he cannot use directly at the resource server) to access 
> Alices cloud storage.
> 
> The attack works as follows:
> 
> First, the attacker visits the website of the client. Usually, the 
> attacker would now choose an AS, and after successful authentication, 
> access his files stored in the cloud. When selecting the AS, the 
> attacker chooses AS_attacker. In Step 5 of Figure 4, AS_attacker now 
> provides the phished access token. As this token is bound to this 
> client, the client can use it at the resource server for getting access 
> to the cloud storage of Alice. As the attacker is using the client 
> (through the clients' website), he now gets access to these files 
> (stored at the RS).
> 
> Please let me know if you have any other questions.
> 
> Best regards,
> Pedram
> 
> 
> On 26.11.19 16:51, Benjamin Kaduk wrote:
> > Hi Pedram,
> >
> > On Thu, Nov 21, 2019 at 02:50:52PM +0100, Pedram Hosseyni wrote:
> >> Also, for this or the next version of this document, the Cuckoo's Token
> >> attack (see Section IV-A of http://arxiv.org/abs/1901.11520/ ), should
> >> be addressed. We also discussed this issue extensively at the last OSW
> >> in Stuttgart.
> > I took a look at the paper, and I'm not sure I'm properly understanding the
> > "Cuckoo's Token" attack.  Looking at Figure 4 of the paper to have
> > something concrete to refer to, I assume that the client, as a white box,
> > is presumed to be honest.  Since the access token is bound to the client, I
> > assume that the attacker has to return the phished access token to the same
> > client that originally (honestly) got it, as otherwise the token will not
> > be usable at the RS.  The paper concludes that in step 6, the client gets
> > access to the honest resource owner's resources, and furthermore that the
> > attacker has access to those resources through the client.  It's that last
> > part that I'm not sure I understand -- if the client is honest, why would
> > it return resource information to the attacker?  The best I can come up
> > with is that there's some sense of a "session" between the user and client,
> > such that the client links its resource accesses with the "session" on
> > behalf of which the access occurs, and is willing to return such
> > information back to the user only on the "linked session".  (The
> > countermeasure makes sense and is a good practice, of course.)
> >
> > Thanks,
> >
> > Ben
> 
> -- 
> Pedram Hosseyni, M.Sc.
> Room V38 2.438
> Institute of Information Security - SEC
> Universität Stuttgart
> Universitätsstraße 38
> D-70569 Stuttgart
> Germany
> Phone: +49 711 685 88454
> https://sec.uni-stuttgart.de
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC review of draft-ietf-oauth-security-topics-13

[Benjamin Kaduk]

Hi Pedram,

On Thu, Nov 21, 2019 at 02:50:52PM +0100, Pedram Hosseyni wrote:
> 
> Also, for this or the next version of this document, the Cuckoo's Token 
> attack (see Section IV-A of http://arxiv.org/abs/1901.11520/ ), should 
> be addressed. We also discussed this issue extensively at the last OSW 
> in Stuttgart.

I took a look at the paper, and I'm not sure I'm properly understanding the
"Cuckoo's Token" attack.  Looking at Figure 4 of the paper to have
something concrete to refer to, I assume that the client, as a white box,
is presumed to be honest.  Since the access token is bound to the client, I
assume that the attacker has to return the phished access token to the same
client that originally (honestly) got it, as otherwise the token will not
be usable at the RS.  The paper concludes that in step 6, the client gets
access to the honest resource owner's resources, and furthermore that the
attacker has access to those resources through the client.  It's that last
part that I'm not sure I understand -- if the client is honest, why would
it return resource information to the attacker?  The best I can come up
with is that there's some sense of a "session" between the user and client,
such that the client links its resource accesses with the "session" on
behalf of which the access occurs, and is willing to return such
information back to the user only on the "linked session".  (The
countermeasure makes sense and is a good practice, of course.)

Thanks,

Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC review of OAuth 2.0 Security Best Current Practice by Mike Jones

[Benjamin Kaduk]

On Wed, Nov 20, 2019 at 03:40:34AM +, Mike Jones wrote:
> I did a complete read of 
> draft-ietf-oauth-security-topics-13.
>   My review comments follow, divided into substantive and editorial sections.
> 
> SUBSTANTIVE
> 
[...]
> 
> 4.8.1.1. Metadata - This section suggests the use of a "resource_servers" 
> metadata value.  This isn't defined by RFC 8414 nor do I see it the IANA 
> OAuth Authorization Server Metadata registry at 
> https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-server-metadata.
>   Is this something that's been standardized elsewhere?  If so, please add a 
> citation.  If not, please clearly say that this metadata value is not 
> standardized, and is therefore unlikely to be interoperable.

I would go further and say that we should not document "best practices"
that involve non-standardized values.

> 4.8.1.1. Metadata - This section suggests the use a 
> "access_token_resource_server" token response value.  Please likewise clearly 
> say that this parameter isn't a standard.

(ditto)

[...]
> 4.8.1.3. Audience Restricted Access Tokens - Delete "basically".
> 
> Many locations - The draft often uses the word "which" when you mean "that".. 
>  For instance, in 4.9.2, please change "which could" to "that could" and in 
> 4.11 change "which are" to "that are".  There's lots of places to look up the 
> difference in meaning, but a rule of thumb that's usually right is that if 
> you don't have a comma before the "which", it should probably be "that".

The RFC Editor uses a "restrictive" vs. "non-restrictive" split for "that"
and "which" -- see https://www.rfc-editor.org/styleguide/tips/ .

-Ben (no hats)

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt

[Benjamin Kaduk]

On Fri, Oct 25, 2019 at 10:02:41AM -0400, Rifaat Shekh-Yusef wrote:
> You might want to look at RFC7239, which is trying to address the issue of
> the loss of information by proxies.
> https://tools.ietf.org/html/rfc7239
> 
> The document does not have a parameter to carry the client certificate
> information, but it allows for new parameters to be defined.
> 
> Would that help in this case?

That is interesting and related, though the proposed work I remember
hearing about recently is not quite in the same space.  Specifically, it
wanted to have a secure protocol between proxy and backend, and it's not
clear that reusing https for that is the right thing.

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt

[Benjamin Kaduk]

On Wed, Oct 23, 2019 at 10:13:04AM -0400, Justin Richer wrote:
>I also agree. Would it be possible to get this pushed to http or tls? It
>would be more appropriate there, and very helpful to have a general spec
>for this.

I think it's possible to get such work done in one of those places, but
first someone has to actually write a draft.  Barring that, a HotRFC or
secdispatch slot in Singapore would probably be good for drumming up
interest.  In related news, I am told that draft-duke-quic-load-balancers
had some time in the QUIC interim this month, and may be moving towards
adoption, so time may be short if we want to have a fully general solution.

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt

[Benjamin Kaduk]

Just on one narrow point:

On Wed, Oct 16, 2019 at 04:23:56PM +0200, Travis Spencer wrote:
> On Sun, Oct 6, 2019 at 3:31 PM Torsten Lodderstedt
> > Open: How would one implement sender constrained access tokens in that 
> > case? I’m asking since the receiving RS obviously has no access to the 
> > information from the TLS handshake since TLS termination happens at the 
> > proxy (or even in before the request hits the proxy). The RS would need to 
> > get provided with the cert fingerprint via a trustworthy header, i.e. the 
> > RS must be aware of the fact it sits behind a proxy.
> 
> This is unfortunately the typical case even with the mTLS draft. This
> is because SSL is almost never terminated by the AS; in my experience,
> TLS termination is instead handled by some very fast proxy.[1] In such
> cases, the proxy will pass the cert through to the AS in some
> undefined HTTP header with some undefined encoding. The mTLS spec
> should have defined this IMO, as it prevents interop for a primary use
> case -- sender constrained tokens.

It's not clear to me that mTLS should have defined a protocol from proxy to
backend; that seems like it could be a fairly generic thing and I know of
several people that are working on similar things, to one degree or
another.  draft-schwartz-tls-lb is the example that I can most easily find
in my archives; though it's working with non-TLS-terminating cases, there
is probably some commonality with TLS-terminating cases as well.

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-jwt-bcp-07: (with COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-jwt-bcp-07: Yes

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-bcp/



--
COMMENT:
--

Thank you for addressing my Discuss (and Comment) points!


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] IANA registry for error codes of RFC6749 section 5.2?

[Benjamin Kaduk]

On Fri, Oct 11, 2019 at 08:17:07AM +0200, Ludwig Seitz wrote:
> On 10/10/2019 17:02, Justin Richer wrote:
> > They are in that registry as the “token endpoint response” error codes. 
> > RFC8628 adds new ones.
> > 
> > I think that 6749 failed to put in the base ones.
> > 
> > — Justin
> 
> That would explain my confusion.
> 
> Errata-worthy?

I think it's not strictly necessary; we can just register the values using
the Specification Required procedure (I sent mail to kick things off
already:
https://mailarchive.ietf.org/arch/msg/oauth-ext-review/4WaM6n6JetFsLI6_T9S8wNVqP74

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt

[Benjamin Kaduk]

On Thu, Sep 26, 2019 at 11:26:31AM +0200, Travis Spencer wrote:
> * Last but certainly not least is the restriction that the current
> version places on disallowing of the introspection JWT response as an
> access token. This is done in numerous places (the note in section 5,
> 8.1, etc.). I understand that there are some objection to this usage,
> but we have had this protocol deployed for years, and it's running in
> dozens of customer's facilities. This will break real applications of
> this specification without a clear alternative. As we discussed in
> London last year at the IETF meeting, token exchange isn't a viable
> alternative (even still in its current draft form to the best of my
> knowledge). Without a workable alternative to move to, I emphatically
> but humbly request that this specification remove this restriction.

I don't think I was in the London session, so would you mind saying a bit
more about why token exchange isn't viable for your scenario?
As an AD, I support the efforts to be explicit about what token flow/usage
is being defined, which in effect means keeping introspection just
introspection and not "producing new tokens".

Thanks,

Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Benjamin Kaduk]

On Wed, Sep 04, 2019 at 06:17:32PM -0600, Brian Campbell wrote:
> On Wed, Sep 4, 2019 at 5:55 PM Benjamin Kaduk  wrote:
> 
> > On Wed, Sep 04, 2019 at 05:19:27PM -0600, Brian Campbell wrote:
> > > Thanks Ben, for the review and non-objectional ballot.
> > >
> > > On Wed, Sep 4, 2019 at 3:13 PM Benjamin Kaduk via Datatracker <
> > > nore...@ietf.org> wrote:
> > >
> > > > Benjamin Kaduk has entered the following ballot position for
> > > > draft-ietf-oauth-resource-indicators-05: No Objection
> > > >
> > > > Section 3
> > > >
> > > >An access token that is audience restricted to a protected resource
> > > >that obtains that token legitimately cannot be used to access
> > > >resources on behalf of the resource owner at other protected
> > > >resources.  The "resource" parameter enables a client to indicate
> > the
> > > >
> > > > nit: This sentence has a pretty strange construction.  I think the
> > > > intent is to say that that a token, legitimately presented to a
> > > > resource, cannot then be taken by that resource server and
> > > > illegitimately present it somewhere else for access to other resources.
> > > > But with the current wording we seem to be missing part of the part
> > > > where some entity obtains the token with intent for illegitimate
> > access.
> > > >
> > >
> > > Yes, despite the pretty strange construction, you have the correct
> > intent.
> > > I'll work on improving that sentence (borrowing heavily from your words
> > > there).
> > >
> > >
> > >
> > > >Some servers may host user content or be multi-tenant.  In order to
> > > >avoid attacks that might confuse a client into sending an access
> > > >token to a resource that is user controlled or is owned by a
> > > >different tenant, it is important to use a specific resource URI
> > > >including a path component.  This will cause any access token issued
> > > >for accessing the user controlled resource to have an invalid
> > > >audience if replayed against the legitimate resource API.
> > > >
> > > > I'm not entirely sure what this is trying to say.  What is the
> > > > "legitimate resource API"?  Why would a token be issued for accessing a
> > > > user-controlled resource if that's something we're trying to avoid
> > > > having confused clients access?
> > > >
> > >
> > > Um... so on rereading that I might say that it's also "pretty strange".
> > >
> > > What it was trying to somehow say is similar to the previous nit about
> > > audience-restricted not being usable at the resource for whom the weren't
> > > intended. But saying so in the context of a multi-tenant environment.
> > > Basically it's trying to say that, in a multi-tenant environment, the
> > > resource URI and subsequent token audience need to have something that
> > > identifies the tenant so as to prevent the token from being used by one
> > > tenant to illegitimately access resources at a different tenant. I'll
> > work
> > > on trying to improve that text to better explain all that.
> >
> > Ah, yes, that's a very good point to make.  I'm happy to look at some draft
> > text if you want.
> >
> 
> Thanks, here's what I've got now for this and the previous item in sec 3.
> Suggestions welcome.
> 
> 3.  Security Considerations
> 
>An audience-restricted access token, legitimately presented to a
>resource, cannot then be taken by that resource to present it
>elsewhere for illegitimate access to other resources.  The "resource"

I think "by that resource and presented elsewhere" probbaly has a more
parallel flow.

>parameter enables a client to indicate the protected resources where
>the requested access token will be used, which in turn enables the
>authorization server to apply the appropriate audience restrictions
>to the token.
> 
>Some servers may host user content or be multi-tenant.  In order to
>avoid attacks where one tenant uses an access token to illegitimately
>access resources owned by a different tenant, it is important to use
>a specific resource URI including any portion of the URI that
>identifies the tenant, such as a path component.  This will allow
>access tokens to be audience-restricted in a way that identifies the
>tenant and prevent their use, due to an invalid audience, at
>resources owned by a different tenant.

But other than the above nit, this all looks really good; thank you!

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Benjamin Kaduk]

On Wed, Sep 04, 2019 at 05:19:27PM -0600, Brian Campbell wrote:
> Thanks Ben, for the review and non-objectional ballot.
> 
> On Wed, Sep 4, 2019 at 3:13 PM Benjamin Kaduk via Datatracker <
> nore...@ietf.org> wrote:
> 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-oauth-resource-indicators-05: No Objection
> 
> --
> > COMMENT:
> > --
> >
> > Abstract
> >
> > This seems to be a sentence fragment (maybe preface with "This document
> > specifies"?).
> >
> 
> Hrm. Yeah, I suppose so. I guess I was trying to be efficient with the
> words but to the point of not having a complete sentence. I'll add that
> preface.
> 
> 
> 
> > Section 2.1
> >
> >For authorization requests sent as a JWTs, such as when using JWT
> >Secured Authorization Request [I-D.ietf-oauth-jwsreq], a single
> >"resource" parameter value is represented as a JSON string while
> >multiple values are represented as an array of strings.
> >
> > jwsreq includes an example with "aud" in the request, yet this new
> > "resource" request parameter is also intended to influence the audience
> > of the resulting token.  I'm not sure whether we need to say anything
> > specifically about this in the document, but I'd like to have a better
> > understanding of how "aud" and "resource" would interact when both
> > present in the reqeust.
> > (This is presumably related to why the request parameter is called
> > "resource" and not "aud" or "audience", but unfortunately I seem to have
> > zoned out for that part of the WG discussion.)
> >
> 
> In the context of a jwsreq request the "aud" indicates the intended
> recipient/audience of the singed authorization request itself, which will
> be the authorization server to whom the request is being made. This
> prevents a singed request meant for AS1 from being used successfully at
> AS2, for example. That "aud" does not do anything to influence the audience
> of the resulting token - it's really just metadata of the signed request
> that will be discarded once the singed request is validated. The "resource"
> parameter of this document indicates where the client intends to use the
> token its requesting, which can and will influence the audience of the
> resulting token. So "aud" and "resource" do not interact when both present
> in a signed authorization request.

Ah, of course; thanks for the refresher, and that makes perfect sense.

> And yes, this is related to why the request parameter is called "resource"
> and not "aud" and also I think related to the outstanding discuss you have
> on jwsreq. If this parameter were to have been called "aud" then there
> would be a name collision when used in conjunction with jwsreq where "aud"
> would have had two distinct and irreconcilable meanings at the same time.
> There are a few other reasons the WG landed on "resource" as the name but
> what you've alluded to up here was a big part of it.

Agreed.

> 
> 
>If the client omits the "resource" parameter when requesting
> >authorization, the authorization server MAY process the request with
> >no specific resource or by using a pre-defined default resource
> >value.  [...]
> >
> > Would/could this default value be global or on a per-scope basis or some
> > other finer granularity than global?
> >
> 
> Yes, it could be any of those. Though I think most likely it'd be global or
> influenced by scope. Really, it'd be whatever that AS was doing in the
> absence of such a parameter before this document came along.

Very true :)

> 
> 
> >  The
> >authorization server might use this data to inform the user about the
> >resources the client is going to access on her behalf, to meet policy
> >decision (e.g. refuse the request due to unknown resources), and
> >determine the set of resources that can be used in subsequent access
> >token requests.
> >
> > nits: comma after "e.g.", and maybe s/meet policy decision/apply policy/
> > (or similar), and "to" before "determine" for parallelism.
> >
> 
> Okay, will do.
> 
> 
> 
> > In Figure 1 we URL-encode the '.'s in "client.example.org" but not in
&g

[OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-resource-indicators-05: 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-resource-indicators/



--
COMMENT:
--

Thank you for this easy-to-read-document -- reducing the risk of using
bearer tokens seems worthwhile, since they are not going away very
quickly.

Abstract

This seems to be a sentence fragment (maybe preface with "This document
specifies"?).

Section 1

   When the
   authorization server is informed of the resource that will process
   the access token, it can restrict the intended audience of that token
   to the given resource such that the token cannot be used successfully
   at other resources.

(This mechanism is only effective if the other resources are
checking in some fashion, whether by direct inspection of a structured
token or by a backchannel to the AS or otherwise, but I hope that
checking 'aud' is standard practice by now!)

Section 2.1

   For authorization requests sent as a JWTs, such as when using JWT
   Secured Authorization Request [I-D.ietf-oauth-jwsreq], a single
   "resource" parameter value is represented as a JSON string while
   multiple values are represented as an array of strings.

jwsreq includes an example with "aud" in the request, yet this new
"resource" request parameter is also intended to influence the audience
of the resulting token.  I'm not sure whether we need to say anything
specifically about this in the document, but I'd like to have a better
understanding of how "aud" and "resource" would interact when both
present in the reqeust.
(This is presumably related to why the request parameter is called
"resource" and not "aud" or "audience", but unfortunately I seem to have
zoned out for that part of the WG discussion.)

   If the client omits the "resource" parameter when requesting
   authorization, the authorization server MAY process the request with
   no specific resource or by using a pre-defined default resource
   value.  [...]

Would/could this default value be global or on a per-scope basis or some
other finer granularity than global?

 The
   authorization server might use this data to inform the user about the
   resources the client is going to access on her behalf, to meet policy
   decision (e.g. refuse the request due to unknown resources), and
   determine the set of resources that can be used in subsequent access
   token requests.

nits: comma after "e.g.", and maybe s/meet policy decision/apply policy/
(or similar), and "to" before "determine" for parallelism.

In Figure 1 we URL-encode the '.'s in "client.example.org" but not in
"api.example.com" in the request URL; should we be consistent?  (This
seems to be recurring throughout the examples.)

Section 2.2

   needs to know.  This further improves privacy as scope values give an
   indication of what services the resource owner uses and downscoping a
   token to only that which is needed for a particular service can limit
   the extent to which such information is revealed across different
   services.  As specified in Section 5.1 of [RFC6749], the

(nit?) I suggest to s/scope values give an indication of what services
the resource owner uses and/a list of scope values is an indication that the
resource owner uses the multiple various services listed;/ since I
misparsed it the first time as-is.

Section 3

   An access token that is audience restricted to a protected resource
   that obtains that token legitimately cannot be used to access
   resources on behalf of the resource owner at other protected
   resources.  The "resource" parameter enables a client to indicate the

nit: This sentence has a pretty strange construction.  I think the
intent is to say that that a token, legitimately presented to a
resource, cannot then be taken by that resource server and
illegitimately present it somewhere else for access to other resources.
But with the current wording we seem to be missing part of the part
where some entity obtains the token with intent for illegitimate access.

   Some servers may host user content or be multi-tenant.  In order to
   avoid attacks that might confuse a client into sending a

[OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-07: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-jwt-introspection-response-07: 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/



--
DISCUSS:
--

Per the ongoing discussion on the WG list, it's unclear that we can
retain the behaviors we describe and still comply with the requirements
of RFC 7519 requirements for being a JWT (e.g., regarding "jti", "iat",
etc.).  That is, in the present formulation, there are two "token"s
involved -- the input that is being introspected, and the "token" that
is the introspection response.  We are claiming that certain fields are
describing the input token, when they are defined to be statements about
the current (response) token.
Relaxing our statements to say that we merely use JWS as opposed to JWT
may be a workaround, though I have thought about it hard enough to have
an opinion on whether it is the best workaround.

I also think we need more clarity about the use of dynamic client
registration by a resource server as outlined in Section 4 (where it's
mentioned as "with a resource server posing as the client", without
reference to RFC 7591.  As far as I can tell this document/section is
introducing this use of dynamic client registration by an RS for the
first time, so we cannot easily just refer to some other document.
Specifically, are there any fields that MUST NOT be supplied?  Is a
human-readable client_name useful?  How does the supplied client_uri
need to relate to any existing AS representation of a resource in
audience, scope, etc. (e.g., for the "resource" request parameter from
draft-ietf-oauth-resource-indicators)?

Is this usage considered to be a "new use of JWTs"?  If so, it seems
that we should follow the recommendation of draft-ietf-oauth-jwt-bcp and
use explicit typing.

I think there are some missing links in the document between a RS
registring client policy and the resulting AS enforcement of encryption
of introspection reponses.  I think the intent is roughly that the
policy will be applied based on the audience of the token being
presented for introspection (as opposed to the identity of the
RS-as-client making the introspection request), but we don't seem to
explicitly say that.  Also, we'd need to say something about the
interaction of multiple RSs' policy when a given token has multiple
valid audiences.  There is a very brief discussion in Section 6.5, but
it seems to be more of a description of what is possible than mandating
particular forms of enforcement.

I think we should discuss whether we want some statement from the OpenID
Foundation or related bodies before we register claims that point to
their documents with the IESG listed as change controller.


--
COMMENT:
--

idnits notes that RFC 5646 is mentioned but not present in the
references section.

Section 1

We probably need to move the 7519 reference up here to where JWT is
first used.

   OAuth 2.0 Token Introspection [RFC7662] specifies a method for a
   protected resource to query an OAuth 2.0 authorization server to
   determine the state of an access token and obtain data associated
   with the access token.  This allows deployments to implement
   identifier-based access tokens in an interoperable way.

Does "identifier-based access tokens" mean "tokens that are opaque keys
to a (central) database lookup" or "access tokens that convey user
identity information" (or something else)?  We may want to tweak the
wording.

Section 3

Can we double-check the base64 form of the response in this example?  I
am seeing output that backslash-escapes the '/' characters in URLs,
which I did not think was needed in this context.
I also see an "extension_field" claim in the base64 but not the decoded
form of the example, and "given_name"/"family_name"/"birthdate" in the
decoded example vs. "username" in the base64 version.

   Note: If the resource server policy requires a signed and encrypted
   response and the authorization server receives an unauthenticated
   request containing an Accept header with content type other than
   "application/jwt", it MUST refuse to serve the request and return an
   HTTP status code

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

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-mtls-17: 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-mtls/



--
COMMENT:
--

Thank you for addressing my Discuss (and Comment!) points!


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-mtls-16: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

On Fri, Aug 23, 2019 at 03:07:43PM -0600, Brian Campbell wrote:
> Thanks for the responses Ben. More inline below with stuff that warrants no
> further discussion snipped out.
> 
> On Thu, Aug 22, 2019 at 5:17 PM Benjamin Kaduk  wrote:
> 
> >
> >   But it's possible to be naive and be correct at the same time...
> >
> 
> I rather like that and suspect I might have to use it in the future :)
> 
> 
> 
> > In terms of proposed text, it looks like after the first paragraph of
> > Section 3 would be a reasonable place, perhaps:
> >
> > In order for a resource server to use certificate-bound access tokens, it
> > must have advance knowledge that mtls is to be used for some or all
> > resource accesses.  In particular, the client ID or access token itself
> > cannot be used as input to the decision of whether or not to use mtls,
> > since from the TLS perspective those are "Application Data", only exchanged
> > after the TLS handshake has been completed, and the initial
> > CertificateRequest occurs during the handshake, before the Application Data
> > is available.  Although subsequent opportunities for a TLS client to
> > present a certificate may be available, e.g., via TLS 1.2 renegotiation
> > [RFC5246] or TLS 1.3 post-handshake authentication [RFC8446], this document
> > makes no provision for their usage.  It is expected to be common that a
> > mtls-using resource server will require mtls for all resources hosted
> > thereupon, or will serve mtls-protected and regular resources on separate
> > hostname+port combinations, though other workflows are possible.  How
> > resource server policy is synchronized with the AS is out of scope for this
> > document.
> >
> > And then the following paragraph could start "Within the scope of an
> > mtls-protected resource-access flow,"
> >
> 
> Thank you for that. Super helpful. I'll incorporate.
> 
> 
> > And my intent and assumption was that a mismatch covered the case where no
> > > certificate was presented (i.e. null cert doesn't match expected cert
> > just
> > > as different cert doesn't match). But perhaps that particular case should
> > > be made more explicit?  The second to last paragraph of sec 3
> >
> > It probably should; "if the presented certificate" as a predicate could
> > fairly be easily read as to ignore the case where no certificate is
> > presented.
> >
> 
> Fair enough. Maybe, "If no certificate is presented or that which is
> presented doesn't match" would suffice to avoid that reading?

I think so :)

> 
> > https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-3 has similar
> > > guidance for error handing in the case of mismatch during resource
> > access.
> > >
> > > The case of a so called public client that has
> > > tls_client_certificate_bound_access_tokens metadata of true that shows up
> > > at the token endpoint without having done MTLS is a bit more nuanced and
> > I
> > > think it's untimely a policy decision for the AS at that point as to
> > > whether to error or issue an unbound token.
> >
> > Do you have any feelings about whether or not you want to mention that case
> > explicitly as being up to local policy at the AS (vs. leaving it implicit
> > as is presently being done)?
> >
> 
> I don't really *want* to add anything but it's probably better to be
> explicit about it. I'll look for a place to work it in.

Okay, thanks.

> 
> 
> >
> > > I am not *nix skilled enough to troubleshoot that command pipeline but I
> > > suspect that the sha256sum output is in hex which represents each byte of
> > > the hash output with two charterers and thus double the resultant size.
> >
> > Please excuse me while I wipe the egg off my face.
> > Yes, that sha256sum output is in hex, and I should have counted the bits
> > directly.  I hope you did not waste too much time on this (and now I can
> > get the thumbprint to agree).
> >
> 
> No worries. I only spent enough time second guessing everything so as to
> try and avoid getting egg on my own face.
> 
> 
> 
> > > > --
> > > > COMMENT:
> > > > --
> > > >
> > > >protected resource access in step (B) is only possible by the
> > > >legitimate client bearing the access token and holding the private
> > > >key corresponding to the certificate

[OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-mtls-16: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-mtls-16: 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-mtls/



--
DISCUSS:
--

(1) I think that we need some text that covers how the resource server
will know to use mtls (and thus, to send a CertificateRequest to the
client during the TLS handshake).  The authorization server and client
can indicate their capabilities/preference via the RFC 8414 and RFC 7591
discovery and registration procedures, but I didn't see any discussion
of how an AS might know a RS's capabilities, or how an RS might develop
expectations of the capabilities of the clients accessing it.  A naive
conclusion might be that any given RS (hostname+port) would have to
either always or never use mtls, given the misordering between TLS
handshake completion and delivery of TLS application data (i.e.,
including the oauth token), though there may be refinements available in
the form of the unpopular TLS 1.2 renegotiation or TLS 1.3
post-handshake authentication (or exported authenticators).  Doing
either of those in an environment with TLS Termination per Section 6.5
may entail additional complications.

(We may also want some additional text discussing error handling for the
client/AS interaction, e.g., if a request shows up from a client-id that
should be using mtls but did not provide a certificate in the TLS
handshake, but that is only debatably something that rises to
Discuss-level; or if a client that advertised an intent to use MTLS used
the regular token endpoint and not the mtls endpoint alias (if they
differ).)

(2) I can't validate the examples in Appendix A.

Specifically, my reading of the text would put the "x5t#S256" value as
needing 86 characters, but only 43 are provided.  The ones there also do
not seem to be a prefix of the result that I get from taking the PEM
certificate contents and running them through the pipeline:

base64 -di | sha256sum |awk '{print $1}'|tr -d '\n'|base64

(Noting, of course, that 'base64' will be producing the non-URL-safe
variant, but expecting it to remain "pretty close".)

I also had some trouble comparing the "y" coordinate from the JWK to the
certificate contents, but that may just be user error.


--
COMMENT:
--

Section 1

nit: in Figure 1, the (C) label is applied to both an arrow and a box
(the other two boxes are not labelled).

   (C)  The protected resource validates the access token in order to
authorize the request.  In some cases, such as when the token is
self-contained and cryptographically secured, the validation can
be done locally by the protected resource.  While other cases
require that the protected resource call out to the
authorization server to determine the state of the token and
obtain meta-information about it.

nit: "While" is a conjunction but this last sentence only has one
clause.

   Layering on the abstract flow above, this document standardizes
   enhanced security options for OAuth 2.0 utilizing client certificate
   based mutual TLS.  Section 2 provides options for authenticating the

nit: "client-certificate-based" is hyphenated.

   request in step (A).  While step (C) is supported with semantics to
   express the binding of the token to the client certificate for both
   local and remote processing in Section 3.1 and Section 3.2
   respectively.  This ensures that, as described in Section 3,

nit: same thing about "while".

   protected resource access in step (B) is only possible by the
   legitimate client bearing the access token and holding the private
   key corresponding to the certificate.

nit: I guess it is only protected resource access "using this tokwn"
that is only possible as specified.

Section 1.2

We probably want to say something like "in addition to the normal TLS
server authentication with a certificate" -- we need both for it to
properly be "mutual" :)

Section 2.1

   The PKI (public key infrastructure) method of mutual TLS OAuth client
   authentication adheres to the way in which X.509 certificates are
   traditionally used for authentication.  It relies on a validated
   certificate chain [RFC5280] and a single subject distinguished name
   (DN) or a single 

Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT)

[Benjamin Kaduk]

On Fri, Jul 19, 2019 at 10:05:57AM -0600, Brian Campbell wrote:
> On Fri, Jul 19, 2019 at 8:31 AM Barry Leiba  wrote:
> 
> >
> > >> — Section 1.1 —
> > >> Given the extensive discussion of impersonation here, what strikes me as
> > >> missing is pointing out that impersonation here is still controlled,
> > that “A is
> > >> B” but only to the extent that’s allowed by the token.  First, it might
> > be
> > >> limited by number of instances (one transaction only), by time of day
> > (only for
> > >> 10 minutes), and by scope (in regard to B’s address book, but not B’s
> > email).
> > >> Second, there is accountability: audit information still shows that the
> > token
> > >> authorized acting as B.  Is that not worth clarifying?
> > >
> > > My initial response was going to be "sure, I'll add some bits in sec 1.1
> > along those lines to clarify
> > > that." However, as I look again at that section for good opportunities
> > to make such additions, I feel
> > > like it is already said that impersonation is controlled.
> > ...
> > > So I think it already says that and I'm gonna have to flip it back and
> > ask if you have concrete
> > > suggestions for changes or additions that would say it more clearly or
> > more to your liking?
> >
> > It is mentioned, true, and that might be enough.  But given that Eve
> > also replied that she would like more here, let me suggest something,
> > the use of which is entirely optional -- take it, don't take it,
> > modify it, riff on it, ignore it completely, as you think best.  What
> > do you think about changing the last sentence of the paragraph?: "For
> > all intents and purposes, when A is impersonating B, A is B within the
> > rights context authorized by the token, which could be limited in
> > scope or time, or by a one-time-use restriction."
> >
> 
> Sure, I think that or some slight modification thereof can work just fine.
> I'll do that and get it and the rest of these changes published when the
> I-D submission embargo is lifted for Montreal.

My brain is apparntly storming and not sleeping.  Another option for
consideration, is to have two sentences:

For all intents and purposes, when A is impersonating B, A is B within the
rights context authorized by the token.  A's ability to impersonate B could
be limited in scope or time, or even with a one-time-use restriction,
whether via the contents of the token or an out-of-band mechanism.

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT)

[Benjamin Kaduk]

On Fri, Jul 19, 2019 at 10:05:57AM -0600, Brian Campbell wrote:
> On Fri, Jul 19, 2019 at 8:31 AM Barry Leiba  wrote:
> 
> > >> — Section 6 —
> > >> Should “TLS” here have a citation and normative reference?
> > >
> > > I didn't include an explicit reference here because TLS is transitively
> > referenced by other
> > > normative references (including 6749 of which this whole thing is an
> > extension) and TLS
> > > is pretty widely recognized even without citation.
> > ...
> > > I'm happy to add a citation here but it does raise the question of what
> > the most appropriate
> > > way to cite TLS is right now - 1.3, 1.2, or the BCP or some combination
> > thereof?
> >
> > I wondered the same thing, and you're also right that it might not
> > need a reference in this document.  I only even flagged it because
> > it's the subject of a MUST.  I'll leave it to the Sec ADs (who
> > obviously didn't flag it themselves, so maybe they agree that it's not
> > necessary).
> >
> 
> I'm gonna just leave it as-is then, unless I hear otherwise from the Sec
> ADs.

I'll throw it out there that "TLS" is marked as "well-known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt ...

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-token-exchange-17: (with COMMENT)

[Benjamin Kaduk]

On Sun, Jul 07, 2019 at 09:32:15AM -0400, Brian Campbell wrote:
> On Sat, Jul 6, 2019 at 2:42 PM Benjamin Kaduk  wrote:
> 
> >
> > > Not to my recollection. I'm honestly not even sure what an array would
> > mean
> > > for "may_act". Do you mean for "act"?
> >
> > Currently we can say that ad...@example.com "may act" as u...@example.com.
> > But IIUC we don't have a way to say that either adm...@example.com or
> > adm...@example.com may do so.  An array would let us indicate multiple
> > authorized parties.  I'm reluctant to actually make such a change at this
> > point, though, since this is already deployed some places, right?
> >
> 
> Okay, sorry, I'm a bit slow but I follow you now.
> 
> Indeed this has been deployed in a number of places already. I'd honestly
> don't know if anyone is making use of this particular claim but changing
> from an object to array of objects would be a breaking change. And a
> breaking change is something I'd really like to avoid unless there's a very
> compelling reason to do so.  And while your point here is taken, I don't
> think it rises to that level of compelling.
> 
> I see two options at this point:
> 1) leave it as is
> 2) adjust the language around  "may_act" such that it could also identify
> an eligible group - this would allow for it to indicate multiple authorized
> parties but just not by one by one name, which is maybe more desirable
> anyway
> 
> What do you think?

Either option is fine with me.  I don't remember how much precedent we have
in the OAuth ecosystem for groups that are  identified in  this manner, but
if it's a fairly common thing that seems to be slighly preferred.
(Even if we go with (1) and this does become an issue at some point, it
shouldn't be too hard to add a "may_also_act" or similar with the array
semantics.)

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-token-exchange-17: (with COMMENT)

[Benjamin Kaduk]

On Sat, Jul 06, 2019 at 08:59:30AM -0400, Brian Campbell wrote:
> Thanks Ben, I'll publish an -18 shortly with these suggestions. A bit more
> detail is inline below.
> 
> 
> On Fri, Jul 5, 2019 at 11:57 PM Benjamin Kaduk via Datatracker <
> nore...@ietf.org> wrote:
> 
> >
> > --
> > COMMENT:
> > --
> >
> > I'm balloting Yes; this document is solid and well-written.
> 
> 
> Thanks!
> 
> 
>   I do have a
> > few additional (largely editorial) suggestions and a question or two,
> > though.
> >
> > Section 2.1
> >
> >The client makes a token exchange request to the token endpoint with
> >an extension grant type using the HTTP "POST" method and including
> >the following parameters using the "application/x-www-form-
> >urlencoded" format with a character encoding of UTF-8 in the HTTP
> >request entity-body as described in Appendix B of RFC6749 [RFC6749].
> >
> > This is a really long sentence.  I see how it got that way, and the RFC
> > Editor staff will probably have some thoughts on how to reword it, but
> > if you happen to have thoughts as well, feel free to have at it.
> >
> 
> I had at it a little bit and broke it up into two sentences.
> 
> 
> 
> >
> > Section 2.2.1
> >
> >expires_in
> >   RECOMMENDED.  The validity lifetime, in seconds, of the token
> >   issued by the authorization server.  Oftentimes the client will
> >   not have the inclination or capability to inspect the content of
> >   the token and this parameter provides a consistent and token type
> >   agnostic indication of how long the token can be expected to be
> >   valid.  For example, the value 1800 denotes that the token will
> >
> > nit: hyphenate "token-type-agnostic".
> >
> 
> done
> 
> 
> 
> > Section 4.4
> >
> > Refresh my memory: did we already have a discussion about may_act as an
> > object vs. an array of objects?
> >
> 
> Not to my recollection. I'm honestly not even sure what an array would mean
> for "may_act". Do you mean for "act"? I suppose an array of objects could
> be used as the value of "act" as a way to express a chain of delegation.
> However, the object with optional nesting seemed (to me) a more natural way
> to express it and has no overhead for the likely most common case of just a
> single actor.

Currently we can say that ad...@example.com "may act" as u...@example.com.
But IIUC we don't have a way to say that either adm...@example.com or
adm...@example.com may do so.  An array would let us indicate multiple
authorized parties.  I'm reluctant to actually make such a change at this
point, though, since this is already deployed some places, right?

-Ben

> 
> 
> 
> >
> > Section 5
> >
> > I'd consider also mentioning/linking the OAuth 2.0 security
> > considerations -- the fact that the STS is colocated with the token
> > endpoint takes care of ensuring a lot of its security properties.
> >
> 
> Makes sense. I'll add that. And refs to RFC6819 and
> draft-ietf-oauth-security-topics to round it out.
> 
> 
> 
> > Section 7
> >
> > It's common (but not required, since it will not be relevant upon
> > publication as an RFC) to note that the indicated values are reflected
> > in early allocations from the indicated IANA registries.  In this case
> > I'd say "don't bother"...
> >
> 
> Not bothering...
> 
> 
> 
> > Appendix B
> >
> > Uh-oh, now we are up to five security ADs that have been around for this
> > document...
> >
> 
>  an oversight on my part and unfortunate reminder about just how long
> this document has been in progress.
> 
> I'll add Roman.
> 
> -- 
> _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-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-token-exchange-17: (with COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-token-exchange-17: Yes

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-token-exchange/



--
COMMENT:
--

I'm balloting Yes; this document is solid and well-written.  I do have a
few additional (largely editorial) suggestions and a question or two,
though.

Section 2.1

   The client makes a token exchange request to the token endpoint with
   an extension grant type using the HTTP "POST" method and including
   the following parameters using the "application/x-www-form-
   urlencoded" format with a character encoding of UTF-8 in the HTTP
   request entity-body as described in Appendix B of RFC6749 [RFC6749].

This is a really long sentence.  I see how it got that way, and the RFC
Editor staff will probably have some thoughts on how to reword it, but
if you happen to have thoughts as well, feel free to have at it.

Section 2.2.1

   expires_in
  RECOMMENDED.  The validity lifetime, in seconds, of the token
  issued by the authorization server.  Oftentimes the client will
  not have the inclination or capability to inspect the content of
  the token and this parameter provides a consistent and token type
  agnostic indication of how long the token can be expected to be
  valid.  For example, the value 1800 denotes that the token will

nit: hyphenate "token-type-agnostic".

Section 4.4

Refresh my memory: did we already have a discussion about may_act as an
object vs. an array of objects?

Section 5

I'd consider also mentioning/linking the OAuth 2.0 security
considerations -- the fact that the STS is colocated with the token
endpoint takes care of ensuring a lot of its security properties.

Section 7

It's common (but not required, since it will not be relevant upon
publication as an RFC) to note that the indicated values are reflected
in early allocations from the indicated IANA registries.  In this case
I'd say "don't bother"...

Appendix B

Uh-oh, now we are up to five security ADs that have been around for this
document...


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-jwsreq-19: 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-jwsreq/



--
DISCUSS:
--

My apologies; my previous position was incomplete.  Updated to note
namespacing issues, and one minor terminology nit about "DNS-ID".

There seem to be some pretty serious namespacing issues that are not
discussed at all in this document.  Specifically, using JWT as a
container for OAuth 2.0 authorization request parameters (including
extension parameters) introduces the usage of many new names (of JSON
name/value pairs) into the JWT claims namespace.  Furthermore, the
addition is not bounded, as any new OAuth extension parameters are
implicitly permitted to be used as well!  The IANA Considerations make
no mention of the collapsed namespace for JWT claims and OAuth 2.0
(authorization request) parameters, leaving substantial potential for
collisions in the future.
Relatedly, using "application/jwt" as the Content-type of the
HTTP response from dereferencing the request_uri with no explicit
indication of the type/profile of JWT used (whether in the content type
or in the JWT claims themselves) gives some risk of misinterpretation of
the content.  Consider, for example, when that request_uri is
dereferenced not by the authorization server in the process of
fulfilling an authorization request, but instead by some other service
that expects a different type of JWT.


This second point is a "discuss discuss" -- it's an important question
and I'd like to talk about it, but it's not clear that any change to the
document will be needed.

The introduction notes as an advantage of JWT that:

   (d)  (collection minimization) The request can be signed by a third
party attesting that the authorization request is compliant with
a certain policy.  For example, a request can be pre-examined by
a third party that all the personal data requested is strictly
necessary to perform the process that the end-user asked for,
and statically signed by that third party.  The authorization
server then examines the signature and shows the conformance
status to the end-user, who would have some assurance as to the
legitimacy of the request when authorizing it.  In some cases,
it may even be desirable to skip the authorization dialogue
under such circumstances.

I'm pretty uncomfortable about suggesting that the authorization
dialogue can/should be skipped; do we need to keep this example?


--
COMMENT:
--

Section 1

   While it is easy to implement, the encoding in the URI does not allow
   application layer security with confidentiality and integrity
   protection to be used.  While TLS is used to offer communication

nit: this wording is a little hard to read; it might be easier to
reorder to "does not allow application layer security to be used to
provide confidentiality and integrity protection".

   The use of application layer security allows requests to be prepared
   by a third party so that a client application cannot request more
   permissions than previously agreed.  This offers an additional degree
   of privacy protection.

(side note) what would an example of such a third party be.  (We already
have the resource owner, the client, and the authorization server ...
maybe it's a fourth party?)

   Furthermore, the request by reference allows the reduction of over-
   the-wire overhead.

We only barely mentioned by-reference at this point (one line in the
Abstract), so I'd suggest "passing the request by reference".

   (4)  its development status that it is an RFC and so is its
associated signing and encryption methods as [RFC7515] and
[RFC7516]

nit: I'd suggest "its development status as a Proposed Standard, along
with the associated signing and encryption methods [RFC7515] [RFC7516]."

   (c)  (confidentiality protection) The request can be encrypted so
that end-to-end confidentiality can be provided even if the TLS
connection is terminated at one point or another.

nit: TLS is always terminated at or before the user-agent, though.  So
maybe the user agent needs to get called out here as well (there could
of course be TLS termin

[OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-jwsreq-19: 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-jwsreq/



--
DISCUSS:
--

This is a "discuss discuss" -- it's an important question and I'd like
to talk about it, but it's not clear that any change to the document
will be needed.

Once this (and some of the more substantive items in the Comment
section) is resolved, I'd be happy to ballot Yes.

The introduction notes as an advantage of JWT that:

   (d)  (collection minimization) The request can be signed by a third
party attesting that the authorization request is compliant with
a certain policy.  For example, a request can be pre-examined by
a third party that all the personal data requested is strictly
necessary to perform the process that the end-user asked for,
and statically signed by that third party.  The authorization
server then examines the signature and shows the conformance
status to the end-user, who would have some assurance as to the
legitimacy of the request when authorizing it.  In some cases,
it may even be desirable to skip the authorization dialogue
under such circumstances.

I'm pretty uncomfortable about suggesting that the authorization
dialogue can/should be skipped; do we need to keep this example?
Maybe just talking about what an expected use case could be would
help alleviate my unease.


--
COMMENT:
--

Section 1

   While it is easy to implement, the encoding in the URI does not allow
   application layer security with confidentiality and integrity
   protection to be used.  While TLS is used to offer communication

nit: this wording is a little hard to read; it might be easier to
reorder to "does not allow application layer security to be used to
provide confidentiality and integrity protection".

   The use of application layer security allows requests to be prepared
   by a third party so that a client application cannot request more
   permissions than previously agreed.  This offers an additional degree
   of privacy protection.

(side note) what would an example of such a third party be.  (We already
have the resource owner, the client, and the authorization server ...
maybe it's a fourth party?)

   Furthermore, the request by reference allows the reduction of over-
   the-wire overhead.

We only barely mentioned by-reference at this point (one line in the
Abstract), so I'd suggest "passing the request by reference".

   (4)  its development status that it is an RFC and so is its
associated signing and encryption methods as [RFC7515] and
[RFC7516]

nit: I'd suggest "its development status as a Proposed Standard, along
with the associated signing and encryption methods [RFC7515] [RFC7516]."

   (c)  (confidentiality protection) The request can be encrypted so
that end-to-end confidentiality can be provided even if the TLS
connection is terminated at one point or another.

nit: TLS is always terminated at or before the user-agent, though.  So
maybe the user agent needs to get called out here as well (there could
of course be TLS termination earlier than the user-agent in some cases,
too).

   2.  When the client does not want to do the crypto.  The
   Authorization Server may provide an endpoint to accept the
   Authorization Request through direct communication with the
   Client so that the Client is authenticated and the channel is TLS
   protected.

How can you "not want to do [the] crypto" but still be doing TLS (with
crypto)?  Perhaps we're looking for "not want to pay the additional
overhead of JWS/JWE cryptography on top of TLS"?

Section 1.1

RFC 8174 has updated BCP 14 boilerplate text to use.

Section 3

nit: should this section be 2.3 to get wrapped into "terminology"?

It might also be worth putting references in for the terms, though they
are largely common knowledge at this point.

Section 4

   A Request Object (Section 2.1) is used to provide authorization
   request parameters for an OAuth 2.0 authorization request.  It MUST
   contains all the OAuth 2.0 [RFC6749] authorization request parameters
   including extension parameters.  The parameters are represented a

[OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-bcp-06: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-jwt-bcp-06: 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-bcp/



--
DISCUSS:
--

Thank you for assembling this document; it will be very valuable to the
community.  I intend to ballot Yes once the following items are
resolved:

Section 2.6 notes:
   Previous versions of the JSON format such as the obsoleted [RFC7159]
   allowed several different character encodings: UTF-8, UTF-16 and UTF-
   32.  This is not the case anymore, with the latest standard [RFC8259]
   only allowing UTF-8.  [...]

The actual situation is a bit more subtle than this text makes it seem;
interoperable JSON can only use non-UTF-8 with explicit mutual
prearrangement in a closed ecosystem.  So, while this statement is true
for Internet JWT usage, it may not be true for *all* JWT usage.
(I do see that in Section 3.7 of this document we do mandate UTF-8 for
JWT, which makes things unambiguous, even if this text here is not
correct.)

Section 3.2 notes:
   JWT libraries SHOULD NOT generate JWTs using "none" unless explicitly
   requested to do by the caller.

I couldn't find anywhere where we have matching guidance about "SHOULD
NOT consume JWTs using 'none' unless explicitly requested"; this seems
important enough to get called out explicitly.


--
COMMENT:
--

I also have some non-Discuss-level substantive comments in the 
section-by-section notes,
in addition to the usual editorial nits.

Section 1

   and/or encrypted.  The JWT specification has seen rapid adoption
   because it encapsulates security-relevant information in one, easy to
   protect location, and because it is easy to implement using widely-

nit: "one easy-to-protect location".

Section 2.2

I'd consider rewording the text here to make it more poignant; perhaps:

  In addition, some applications use a keyed MAC algorithm such as
  "HS256" to sign tokens, but supply a weak symmetric key with
  insufficient entropy (such as a human memorable password).  Such keys
  are vulnerable to offline brute-force or dictionary attacks once an
  attacker possesses such a token.

Section 2.4

I'd suggest noting that the compression attacks are particularly
powerful when there is attacker-controlled data in the same compression
space as secret data.

Section 3.2

   Therefore, applications MUST only allow the use of cryptographically
   current algorithms that meet the security requirements of the
   application.  This set will vary over time as new algorithms are
   introduced and existing algorithms are deprecated due to discovered
   cryptographic weaknesses.  Applications MUST therefore be designed to
   enable cryptographic agility.

This seems to have high overlap with BCP 201; a reference is probably in
order.

Section 3.4

   Some cryptographic operations, such as Elliptic Curve Diffie-Hellman
   key agreement ("ECDH-ES") take inputs that may contain invalid
   values, such as points not on the specified elliptic curve or other
   invalid points (see e.g.  [Valenta], Sec. 7.1).  Either the JWS/JWE
   library itself must validate these inputs before using them or it
   must use underlying cryptographic libraries that do so (or both!).

side note: A phrasing like "JWS/JWE libraries MUST ensure that such
input validation occurs" would leave the same wiggle room for the
validation to occur at the underlying crypto layer, while leaving it
crystal clear what entity is responsible for ensuring that the checks
occur".  But since I don't expect a change of this nature to actually
cause different behavior by implementors, I'm not very tied to it.

Section 3.8

When we say "[o]ther applications may use different means of binding
keys to issuers", is there any value in noting that certification by a
trusted authority is a common way to perform this binding (in some
contexts)?

Section 3.9

   If the same issuer can issue JWTs that are intended for use by more
   than one relying party or application, the JWT MUST contain an "aud"
   (audience) claim that can be used to determine whether the JWT is
   being used by an intended party or was substituted by an attacker at
   an unintended party.  Furthermore, the relying party or application
   MUST vali

Re: [OAUTH-WG] MTLS vs. DPOP

[Benjamin Kaduk]

On Tue, May 07, 2019 at 11:18:21AM -0600, Brian Campbell wrote:
> Practically speaking there's the MTLS draft, which has been sent to the
> IESG for publication, has commercial and opensource implementations as well
> as production deployments, and is referenced by other prospective standards
> and profiles. It's not uncommon to receive off list inquires about the
> document status from people involved in those things asking when it will be
> "finished". Which is to say that there's a good amount of interest from the
> community at large in seeing the MTLS document go to RFC. And it's
> relatively close to doing so (as these things go anyway). The DPoP
> document, on the other hand, is currently an individual draft submission.
> And while it has generated some good interest and discussion, it is only an
> individual draft submission and carries the same authority as any other
> individual draft submission (see
> https://tools.ietf.org/html/draft-abr-twitter-reply-00 for example). I
> believe that the MTLS draft should continue on the it's course. And am
> interested in seeing where we can take the DPoP work and if the WG wants to
> take it on.
> 
> Your point about the "PR" perspective is taken. And I probably shouldn't
> even bring these up but that whole situation is exacerbated by the
> expired/dormant WG documents like draft-ietf-oauth-token-binding and
> draft-ietf-oauth-signed-http-request. Some organizations out there touting

I've forgotten the details of those two documents, but in the general case,
if there's a WG document that is no longer actively being worked on (or is
now believed to be a bad idea), the chairs can pretty easily get a new rev
posted that has a "tombstone" notice, like "this document is no longer
being worked on" or similar, which may help clarify the situation to
external parties without much investment on time or tooling.

-Ben

> their support for RFC 7800 as a complete solution in the
> pop/sender-constrained space aren't helping matters either. So while I
> think I hear what you are saying, I don't personally see much of anything
> reasonable or actionable that can done about it.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth