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

[Jared Jennings]

Hi Vittorio,

Yeah, this does make a bit of sense. So, the goal is to guide implementors from 
making bad choices, not from a security perspective. Meaning, it's not a 
security risk that a client does inspect or analyze the token. Instead, it's is 
an interop issue and thus we are guiding implementors to never assume or expect 
the token format to be consistent or of a expected format, for various reasons. 
I kinda know the answer to this question, but I am kinda asking this way to 
help restate the intent of the "topic" and maybe help guide to a wording that 
works for everyone.

For example, as a consultant, it can be very helpful to know how to decompile 
or inspect an "Object", but at the same time knowing that such a method or 
practice should never be used in production.

Jared


> On May 11, 2020, at 19:24, Vittorio Bertocci  
> wrote:
> 
> Real world scenarios are full of situations where additional assumptions can 
> lower dangers that must be taken in consideration in the general case, which 
> might make less of a risk going against the specin those particular 
> circumstances, but their existence doesn’t warrant relaxing guidance for the 
> general case. A concrete example: I worked on scenarios where resource 
> servers wanted to guarantee some degree of business continuity in case of AS 
> outage, which boiled down to RS’ willingness to accept ATs past their 
> declared expiration time, on the condition that the AS outage condition was 
> detectable and the staleness of the AT didn’t cross a tolerance threshold. 
> The business scenario made sense, and the implementer was within their right 
> in deciding that disregarding exp in those circumstances was acceptable. 
> Nonetheless, I would not argue that given the existence of that scenario, 
> rfc7519 should turn its MUST NOT into a SHOULD NOT.
> 

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

[Jared Jennings]

If I may, step in and offer a suggestion.

What if instead of "MUST NOT" replace with "SHOULD NOT"?

To me, (and this might be me), but MUST NOT describes a violation. As in I
broke the law. Conversely, I interpret, "SHOULD NOT" as a recommendation, a
guideline, best practice, etc.

If then the sentence went on to explain why you should not inspect the
token, the risk is therefore known and on the "implementer" of the
inspection.

Jared


On Mon, May 11, 2020 at 7:34 AM Denis  wrote:

> Hi Benjamin,
>
> We are making progress since we now understand better each other. You
> wrote several sentences on which I agree:
>
> "I do in fact agree that token inspection by a client can be useful in at
> least some situations".
>
> "I fully support having privacy considerations sections that discuss the
> privacy properties of the protocol in question,
>   *e**ven including aspects that are currently lacking*.
>
> "I do not believe that a JWT profile for OAuth use is the place to make
> changes to the core OAuth protocol that improve its privacy properties".
>
> I also accept your apologies.
>
> RFC 6749 is quite clear in section 1.4 that "The string [access token] *is
> usually opaqu**e* to the client".
> However, it does not mean that : "The client *MUST NOT* inspect the
> content of the access token".
> I believe the wording I proposed corresponds to the reality:
>
> There is no guarantee that token inspection can always be performed.
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Aligning PKCE requirements within the OAuth Security BCP

[Jared Jennings]

As a clarifying question, you are saying "Servers must support" and not
"Servers must require clients to use PKCE".

-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp: +1 816.678.4152


On Wed, May 6, 2020 at 4:04 PM Mike Jones  wrote:

> As is being discussed in the thread “[OAUTH-WG] OAuth 2.1 - require
> PKCE?”,
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2..1..1
> 
> has inconsistent requirements for PKCE support between clients and
> servers.  Per the first paragraph, clients must either use PKCE or use the
> OpenID Connect nonce to prevent authorization code injection.  Whereas the
> fourth paragraph says “*Authorization servers MUST support PKCE [RFC7636]*.”.
> This imposes a requirement on servers that isn’t present for corresponding
> clients.  (I missed this internal discrepancy within the specification when
> I did my review.)
>
>
>
> I therefore request that the fourth paragraph by change to read: “*OAuth
> Servers MUST support PKCE [RFC7636] unless they are only used for OpenID
> Connect Authentication Requests*”, making the requirements on clients and
> servers parallel.  That way PKCE will still be there unless you don’t need
> it.  (And it still could be there if the server implementer chooses to have
> it in all cases, but that should be their call.)
>
>
>
>Thank you,
>
>-- Mike
>
>
> ___
> 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] Refreshing tokens on the RS

[Jared Jennings]

Not exactly the same, but seems similar to some of the proposed logic in
https://tools.ietf.org/wg/oauth/draft-ietf-oauth-incremental-authz/

-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp: +1 816.678.4152


On Tue, May 5, 2020 at 10:19 AM Jim Schaad  wrote:

> Over in the ACE working group we are currently having a discussion about
> refreshing tokens on an RS.  I want to make sure that this is not something
> that this working group has already solved.  The basic scenario is:
>
> 1.  Client gets token T1 and posts it to the RS
> 2.  After some time the RS returns and error to the client about an access
> issue
> 3.  Client gets a new token from the AS T2, possibly using a refresh token.
> 4. Client posts the token T2 to the RS
> 5.  The RS somehow needs to associate token T1 and T2 for long term
> security
> sessions.
>
> I do not believe that OAuth has this issue because there is not currently
> any concept that a token is used for anything other than a single
> request/response between the client and the RS.  There is no idea of the RS
> storing tokens long term associated with a TLS session that might need to
> have the access rights for that TLS session changed.
>
> Please provide any feedback that you might have.
>
> Thanks
> Jim
>
>
> ___
> 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] May 11th Interim Meeting Materials

[Jared Jennings]

I will be taking notes using the following link.
https://docs.google.com/document/d/1tPxkaOf74szvDLSEpzXV8lMgSEwcHYMC73OUOv3BKxQ/edit?usp=sharing

-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp: +1 816.678.4152


On Fri, May 8, 2020 at 5:25 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> You can find the meeting material for the May 11th meeting at the
> following link:
> https://datatracker.ietf.org/meeting/interim-2020-oauth-08/session/oauth
>
> Regards,
>  Rifaat
>
> ___
> 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] May 4th Interim Meeting Material

[Jared Jennings]

I'll be taking notes here
https://docs.google.com/document/d/1gVTUzkMFvS-XyrYBiXOqbUnl5zp5nlhZf57oKFY2bzc/edit?usp=sharing

Of course, Rifaat will publish once complete.

-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp: +1 816.678.4152


On Sun, May 3, 2020 at 4:02 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> Here is a link to the meeting material for tomorrow's meeting:
> https://datatracker.ietf.org/meeting/interim-2020-oauth-07/session/oauth
>
> Regards,
>  Rifaat & Hannes
> ___
> 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-WG] Structured management of working documents

[Jared Jennings]

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.

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

Thanks for listening.

-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp: +1 816.678.4152
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] RAR - Example JWT for Payment

[Jared Jennings]

I have a question about the example and maybe it's more for
clarification than anything.

The example contains type and also location.
A couple of things
1. Would it add clarity if the domain was the same for both? vs. someorg.com
/ example.com
2. While only an example, would it bring clerity to past examples if the
type was https://schema.example.com/payment_initiation and the location was
https://api.example.com/payments

or am I missing something what the values represent?

Here's the example I am referring to on page 17.

{
  "iss": "https://as.example.com;,
  "sub": "24400320",
  "aud": "a7AfcPcsl2",
  "exp": 1311281970,
  "acr": "psd2_sca",
  "txn": "8b4729cc-32e4-4370-8cf0-5796154d1296",
  "authorization_details": [
 {
"type": "https://www.someorg.com/payment_initiation;,
"actions": [
   "initiate",
   "status",
   "cancel"
],
"locations": [
   "https://example.com/payments;
],
"instructedAmount": {
   "currency": "EUR",
   "amount": "123.50"
},
"creditorName": "Merchant123",
"creditorAccount": {
   "iban": "DE02100100109307118603"
},
"remittanceInformationUnstructured": "Ref Number Merchant"
 }
  ],
  "debtorAccount": {
 "iban": "DE40100100103307118608",
 "user_role": "owner"
  }
   ]


-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp: +1 816.678.4152
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.1 - drop implicit flow?

[Jared Jennings]

Perfect, and really good info! but most people, if we need to worry about
the audience, are not going to put that together. They just read "OAUTH".
It's not a deal breaker, but if the document is going to be easy to read
and keep confusion to a minimum... then it would be nice if it addressed
concepts like this that might seem obvious to you.

Granted, I am coming at this from a consultant perspective who works with a
lot of companies who have architects that barely understand these
technologies, but are implementing them for the enterprise.

-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp: +1 816.678.4152


On Wed, Mar 18, 2020 at 7:55 AM Justin Richer  wrote:

> OpenID Connect is based on OAuth 2.0, not on OAuth 2.1. Therefore, it
> would not be affected at all, whether through the hybrid or implicit flows.
>
> If OIDC pushes a revision to OAuth 2.1, then it would be bound by the
> features of OAuth 2.1 and would need to contend with that. But until that
> happens, everything we do with OAuth 2.1 has literally no effect on OAuth
> 2.0 systems, including OIDC.
>
>  — Justin
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.1 - drop implicit flow?

[Jared Jennings]

I agree, but would add that as long as it says "this is being drop", but
does not impact "that", then the reader can understand context. "This does
not change support for implicit response that OpenID Connect (OIDC) makes
use of".

my two cents.

-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp: +1 816.678.4152


On Thu, Mar 12, 2020 at 1:15 PM Vittorio Bertocci  wrote:

> Sorry for the delay here.
> From the formal perspective, Torsten's language works for me as well.
> Thanks for taking the feedback into account.
>
> I still worry that without an explicit reference to OIDC
> implicit+form_post, I will have the conversation "but can we still do this
> in OIDC now that implicit has been deprecated in OAuth?" countless times
> with customers, but I'm resigned to that anyway :)
>
>
> On Sat, Mar 7, 2020 at 3:36 PM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
>> Sorry, was replying i. my phone on the weekend and trying to keep it
>> quick. I meant that I thought Torsten's suggestion was good.
>>
>> On Sat, Mar 7, 2020, 4:25 PM Dick Hardt  wrote:
>>
>>> Would you clarify what text works Brian?
>>>
>>> On Sat, Mar 7, 2020 at 3:24 PM Brian Campbell <
>>> bcampb...@pingidentity.com> wrote:
>>>
 Yeah, that works for me.

 On Sat, Mar 7, 2020, 9:37 AM Dick Hardt  wrote:

> Brian: does that meet your requirements?
>
> If not, how about if we refer to OIDC as an example extension without
> saying it is implicit?
> ᐧ
>
> On Sat, Mar 7, 2020 at 8:29 AM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> I think keeping the response type as extension point and not
>> mentioning implicit at all is sufficient to support Brian’s objective.
>>
>> Am 07.03.2020 um 17:06 schrieb Dick Hardt :
>>
>> 
>> How about if we add in a nonnormative reference to OIDC as an
>> explicit example of an extension:
>>
>> "For example, OIDC defines an implicit grant with additional security
>> features."
>>
>> or similar language
>> ᐧ
>>
>> On Sat, Mar 7, 2020 at 5:27 AM Brian Campbell <
>> bcampb...@pingidentity.com> wrote:
>>
>>> The name implicit grant is unfortunately somewhat
>>> misleading/confusing but, for the case at hand, the extension mechanism
>>> isn't grant type so much as response type and even response mode.
>>>
>>> The perspective shared during the office hours call was,
>>> paraphrasing as best I can, that there are legitimate uses of implicit
>>> style flows in OpenID Connect (that likely won't be updated) and it 
>>> would
>>> be really nice if this new 2.1 or whatever it's going to be document 
>>> didn't
>>> imply that they were disallowed or problematic or otherwise create
>>> unnecessary FUD or confusion for the large population of existing
>>> deployments..
>>>
>>> On Fri, Feb 28, 2020 at 1:56 PM Dick Hardt 
>>> wrote:
>>>
 I'm looking to close out this topic. I heard that Brian and
 Vittorio shared some points of view in the office hours, and wanted to
 confirm:

 + Remove implicit flow from OAuth 2.1 and continue to highlight
 that grant types are an extension mechanism.

 For example, if OpenID Connect were to be updated to refer to OAuth
 2.1 rather than OAuth 2..0, OIDC could define the implicit grant type 
 with
 all the appropriate considerations.


 ᐧ

 On Tue, Feb 18, 2020 at 10:49 PM Dominick Baier <
 dba...@leastprivilege.com> wrote:

> No - please get rid of it.
>
> ———
> Dominick Baier
>
> On 18. February 2020 at 21:32:31, Dick Hardt (dick.ha...@gmail.com)
> wrote:
>
> Hey List
>
> (I'm using the OAuth 2.1 name as a placeholder for the doc that
> Aaron, Torsten, and I are working on)
>
> Given the points Aaron brought up in
>
>
> https://mailarchive.ietf.org/arch/msg/oauth/hXEfLXgEqrUQVi7Qy8X_279DCNU
>
>
> Does anyone have concerns with dropping the implicit flow from the
> OAuth 2.1 document so that developers don't use it?
>
> /Dick
> ___
> 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.*

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

[Jared Jennings]

+1

-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp: +1 816.678.4152


On Mon, Nov 25, 2019 at 8:08 AM Neil Madden 
wrote:

> On 25 Nov 2019, at 12:09, Torsten Lodderstedt 
> wrote:
> >
> > Hi Neil,
> >
> >> On 25. Nov 2019, at 12:38, Neil Madden 
> wrote:
> >>
> > Do you think we should spell this out in the SPA BCP?
>
> I think that would certainly be a great start.
>
> -- 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-WG] review draft-ietf-oauth-security-topics-13 : JJennings

[Jared Jennings]

A few comments and changes that I think should be made or would read more
clearly.

3.1 Paragraph #2
Should probably read either of the following

Clients SHOULD avoid forwarding the user's browser to a URI obtained
   from a query parameter since such a function could be utilized to
   exfiltrate authorization codes and access tokens.  If there is a
   strong need for this kind of *redirect*, clients are advised to
   implement appropriate countermeasures against open redirection, e.g.,
   as described by OWASP [owasp
].

or

Clients SHOULD avoid forwarding the user's browser to a URI obtained
   from a query parameter since such a function could be utilized to
   exfiltrate authorization codes and access tokens.  If there is a
   strong need for *these* kind of redirects, clients are advised to
   implement appropriate countermeasures against open redirection, e.g.,
   as described by OWASP [owasp
].


3.1.1
Last Paragraph
Either should start with AS, like the others or server should be uppercase?

 Authorization servers SHOULD furthermore consider the recommendations
   given in [RFC6819], Section 4.4.1.1
, on
authorization code replay
   prevention.


4.4.1, 4.5.2
The beginnings of each bullet list should be capitalized? (The)

4.8.1.3
Should maybe read

An audience restriction essentially restricts access tokens to a
particular resource server. The authorization server

   associates the access token with the particular resource server and
thus a resource server SHOULD verify the
   intended audience. If the access token fails the intended audience
validation, the resource server must refuse

   to serve the respective request.


.

The client SHOULD to tell the authorization server the intended
resource server.  The proposed
   mechanism [I-D.ietf-oauth-resource-indicators
]
could be used or by encoding the
   information in the scope value.




   Audience restriction may seem easier to use since it does not require
any crypto on the client-side. Still, since every access token is bound to
a specific resource server, the client also needs to obtain a single
RS-specific access token when accessing several resource servers.
 [I-D.ietf-oauth-token-binding] has the same property since different token
binding ids must be associated with the access token.  Using
[I-D.ietf-oauth-mtls], on the other hand, allows a client to use the access
token at multiple resource servers.

4.8.2 I think would read better with the following
An attacker may compromise a resource server to gain access and to other
resources of the respective deployment. Such a compromise may range from
partial access to the system, e.g., its log files, to full control of the
respective server.

If the attacker were able to gain full control, including shell access, it
would be able to circumvent all controls and access resources. It would
also obtain other access tokens held on the compromised system, which would
potentially be valid to access other resource servers.

Preventing server breaches by hardening and monitoring server systems is
considered a standard operational procedure and, therefore, out of the
scope of this document. This section focuses on the impact of such
 OAuth-related breaches and the replaying of captured access tokens.

4.9.1
Attackers could try to utilize a user’s trust in the authorization server
(and its URL in particular) for performing phishing attacks.

 [RFC6749], Section 4.1.2.1, already prevents open redirects by stating the
AS MUST NOT automatically redirect the user agent in case of an invalid
combination of client_id and redirect_uri.

However, as described in [I-D.ietf-oauth-closing-redirectors], an attacker
could also utilize a correctly registered redirect URI to perform phishing
attacks. It could, for example, register a client via dynamic client
registration [RFC7591] and intentionally send an erroneous authorization
request, e.g., by using an invalid scope value, thus redirecting
instructing the AS to redirect the client to the desired phishing site.

The AS MUST take precautions to prevent this threat. Based on its risk
assessment, the AS needs to decide whether it can trust the redirect URI
and SHOULD only automatically redirect the user agent if it trusts the
redirect URI. If the URI is not trusted, it MAY inform the user and rely on
the user to make the correct decision.


4.9.2
Clients MUST NOT expose URLs, which could be utilized as an open
redirector. Attackers may use an open redirector to produce URLs that
appear to point to the client, which might trick users into trusting the
URL and following it in their browser. Another abuse case is to produce
URLs pointing to the client and 

Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"

[Jared Jennings]

Hi,

This is my first time reviewing a document or responding to the group. So,
with that introduction feel free to guide me along the way.

Reading through the document, I had a few high-level questions first. I
will have more detailed comments later, once I know I'm on the right track
and I assume those comments I should just share with the mailing list?

1. Since the document is a "Best Practices" document, are the words "MUST"
and "REQUIRED" and other definitive terms? Would instead SHOULD and
RECOMMENDED be used?

2. Should other possible threats and vulnerabilities be included? Meaning,
is the list the definitive known list?

Thanks!
-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp: +1 816.678.4152



On Wed, Nov 6, 2019 at 2:27 AM Hannes Tschofenig 
wrote:

> Hi all,
>
> this is a working group last call for "OAuth 2.0 Security Best Current
> Practice".
>
> Here is the document:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13
>
> Please send you comments to the OAuth mailing list by Nov. 27, 2019.
> (We use a three week WGLC because of the IETF meeting.)
>
> Ciao
> Hannes & Rifaat
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. 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