Re: [OAUTH-WG] Your opinion about draft-ideskog-assisted-token

[Travis Spencer]

On Fri, Feb 19, 2021 at 10:09 PM Brian Campbell
 wrote:
> Publishing an independent stream RFC that runs contrary to the BCP
> coming out of the WG does seem potentially harmful.
>
> On Mon, Feb 15, 2021 at 11:59 AM RFC ISE (Adrian Farrel) 
>  wrote:
>> I want to be sure that ... there is no perceived harm to existing
>> OAuth work if this goes ahead

It is my understanding that the procedure that an informational RFC
goes through is that if "(a) the IESG recommends that the document
be brought within the IETF and progressed within the IETF context,
but the author declines to do so, or (b) the IESG considers that
the document proposes something that conflicts with, or is actually
inimical [i.e., 'harmful'] to, an established IETF effort, the
document may still be published as an Experimental or Informational
RFC," (RFC 2026, section 4.2.3). RFC 5742 updates this with a
"compatible" description that states in section 3 that the IESG
review of an independent submission may recommend not to publish
the draft because the IESG "concluded that publication could
potentially disrupt the IETF work done in WG ". My question is
how could this draft disrupt this working group's work?

Is it because it will be unclear to the market what advice they
should follow when implementing single page applications? That could
be a reason, some may argue, to not publish this document by this
working group. This is not justification, in my opinion, however,
for recommending that it not at least be published outside this
working group. I say this because RFC 7221 says in section 5.3 that
"[e]ngineering for interesting topics often produces competing,
interesting proposals... Although it is far more comfortable to
entertain only one proposal, a working group is free to pursue
more than one. Often this is necessary until a clear preference
develops. Sometimes, multiple versions are formally published,
absent consensus among the alternatives."

RFC 7221 goes on to describe how to deal with competing drafts. We
feel that we have followed those guidelines for the betterment of
all. For instance, we have contributed to the BCP that Brian
mentioned[1], and agree that this is a good set of recommendations.
The results proposed in the BCP are ones that our customers will
hopefully follow when applicable. The combined results in the BCP do
not detract from the usefulness of the assisted token protocol we
have defined, in my opinion. This should not surprise us when we
consider that we "IETF participants devise solutions for the global
Internet that meet the needs of diverse technical and operational
environments," (RFC 7153, section 3). This diversity will require
multiple methods to solve a wide array of problems. This need is
reflected in the enthusiasm of reviewers' comments I have received
since draft 4 was published recently wherein one reviewer states,
that they are "looking forward to see the assisted token endpoint
being implemented by clients and IdPs." I have received similar
comments before as well. This leads me to conclude that it isn't
just me that thinks that this protocol is generally useful.

Furthermore, RFC 7221 also says in section 5.2 that "If a working
group drops a draft, then anyone is permitted to pursue it as an
Individual or Independent Submission." While the working group never
adopted this draft, the implication of the statement is that any I-D
that the working group opted not to take up can also be submitted to
the independent stream. One of the reasons for this non-standard
track, as stated in RFC 4846 section 2, is to describe "Documents
considered by IETF Working Groups but not standardized."

Another is to give place to dissenting views, so they can reach the
broader Internet community when consensus cannot be established
within a working group. If a working group has the possibility to
prevent publication outside of its boundaries (e.g., in the
independent stream), this purpose of an alternative publication
venue cannot be achieved. When I read RFC 4846, I am left
with the view that this is one of the primary purposes of the
independent stream. There it says in section 2:

Independent Submissions are especially important as checks on
the IETF processes even though such checks are not the only, or
even a common, reason for them. That role is compromised if IETF-
related entities are able to block or deprecate such documents to
a degree beyond that needed to avoid difficulties with the
standards processIndependent Submissions have become
important[because they include] Critiques and discussions
of alternatives to IETF Standards-Track protocols. The potential
for such critiques provides an important check on the IETF's
standards processes and should be seen in that light.

For this reason, I think the OAuth working group should either
accept this document (though I'm not sure I'm willing to yield
control of it any longer) or not hinder its publication 

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Neil Madden]

I was mentioning it primarily as another example of the assumption that GET 
requests are safe. However, the draft rfc6265bis [1] does seem concerned about 
this, and mentions  as a possible attack vector. This would 
again potentially pull the access token into the renderer’s memory space (until 
site isolation becomes widespread). 

I also have a general dislike of SameSite cookies as a defence against CSRF. 
There are CSRF-like attacks that are not strictly cross-*site* but are 
cross-origin (CORF?). For example, subdomain hijacking is relatively common [2] 
and completely defeats SameSite. As the draft itself says [3]:



   "SameSite" cookies offer a robust defense against CSRF attack when
   deployed in strict mode, and when supported by the client.  It is,
   however, prudent to ensure that this designation is not the extent of
   a site's defense against CSRF, as same-site navigations and
   submissions can certainly be executed in conjunction with other
   attack vectors such as cross-site scripting.

   Developers are strongly encouraged to deploy the usual server-side
   defenses (CSRF tokens, ensuring that "safe" HTTP methods are
   idempotent, etc) to mitigate the risk more fully.


If we recommend SameSite for this, IMO we should do so only with the same 
caveats expressed in the httpbis draft. 

[1]: 
https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-07#section-5.3.7.1
[2]: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers#
[3]: https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-07#section-8.8.1

Cheers,

Neil

> On 19 Feb 2021, at 23:18, Brian Campbell  wrote:
> 
> 
> Thanks Neil, 
> Appreciate the insight and recommendations. I think we can incorporate that, 
> more or less, into the next revision. 
> One point to dig into just a bit more, you said that 'SameSite has a "GET-out 
> clause" in the form of “lax”'. As I understand it, such a cookie would still 
> only be sent on a cross-site GET resulting from a top-level  navigation. And 
> in the context of the bff-token endpoint, that significantly reduces the ways 
> a cross-site request could be initiated and those ways (pop-up or full page 
> redirection) further limits the likelihood of the malicious party being able 
> to read response data. 
> 
>> On Thu, Feb 18, 2021 at 5:08 AM Neil Madden  
>> wrote:
>> Thanks for following up, Brian. Responses below.
>> 
>>> On 17 Feb 2021, at 22:48, Brian Campbell  wrote:
>>> 
>>> Always appreciate (and often learn from) your insights, Neil. I'd like to 
>>> dig into the CSRF thing a bit more though to understand better and 
>>> hopefully do the right thing in the draft. 
>>> 
>>> It seems to me that a GET at the bff-token endpoint is "safe" in that it's 
>>> effectively just a read.
>> 
>> Well it’s a read that returns an access token. It’s “safe” in the sense of 
>> side-effects, but we absolutely want to preserve the confidentiality of what 
>> is returned and only allow it to be accessed by authorized clients (the 
>> legitimate frontend). At the moment the only thing keeping that safe is the 
>> JSON content type. For example, imagine a world in which the token-bff 
>> endpoint instead returned the access token as HTML:
>> 
>> abcd
>> 
>> Then as an attacker I can simply embed an iframe on my site that refers to 
>> your bff-endpoint and then parse the access token out of the DOM. The 
>> browser will happily load that iframe and send along the cookie when it 
>> makes the request. If you have CORS enabled on your site (with 
>> Access-Control-Allow-Credentials) then any of the allowed CORS origins can 
>> directly call the bff-token endpoint and read the access token even in JSON 
>> form. There have also been historical same-origin policy bypasses using 
>> Flash, Adobe Reader, or other plugins (thankfully now largely eliminated), 
>> or by redefining JavaScript prototypes - see 
>> https://haacked.com/archive/2009/06/25/json-hijacking.aspx/ . These are 
>> largely fixed, but I wouldn’t bet on there never being another one.
>> 
>> 
>>> There could be a "cache miss" where the backend attempts to use a refresh 
>>> token it has to get a new access token from the remote AS, which will be 
>>> more resource intensive but doesn't fundamentally alter the state of the 
>>> backend so is still "safe". That in conjunction with your pointing to 
>>> Cross-Origin Read Blocking makes me think your concern isn't so much about 
>>> traditional CSRF used to take some malicious action but rather about 
>>> somehow (speculative side-channel attacks, problems with javascript 
>>> interpreters, other similar vectors that are somewhat beyond me) accessing 
>>> the data of the response to a forged cross site request. Correct me if I'm 
>>> wrong. I don't know if or how much the distinction matters in terms of 
>>> mitigation approach but I'm keen to better understand.  
>> 
>> As explained above, because the endpoint returns JSON it _should_ be 
>> impossible to directly read the 

Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-access-token-jwt-11

[Vittorio Bertocci]

Thank you Joseph for your comments!

> 1.  (Editorial) What is the relationship between this document and RFC 7523. 
>   They are using JWT for different purposes, but I think it would be useful to
>clarify this in the introduction.
Good point, I agree it would be good to preempt doubts on this. I am suggesting 
to append the following language to the current introduction (pardon the XML).

Please note: although both this document and  both use 
JSON Web Tokens in the context of the OAuth2 framework, the two specifications 
differ in both intent and mechanics. Whereas  defines 
how a JWT Bearer Token can be used to request an access token, this documents 
describes how to encode access tokens in JWT format.

>2.  (Issue) The specification does not specify any mandatory to implement 
> for
>the recommended asymmetric algorithms.  This will not help interop.  
> Perhaps
>specify one or both of  "RS256" and "ES256".
The current text doesn’t mandate a format for two main reasons: 
- thanks to the AS metadata the negotiation between a RS and an AS is very easy 
to perform, hence the likelihood of interop issues at runtime is very low
- worries that as crypto advances, what we mandate at this point might no 
longer be suitable.
That said, if you feel strongly about this please do let me know, and I will be 
OK with adding RS256 as a mandatory supported alg for both AS and RS.
From a cursory check, ES256 doesn’t seem to enjoy as widespread support at the 
moment (see https://jwt.io/ libraries list) hence I would be hesitant to make 
it mandatory. 

>3. (Question) Is it currently possible to use the JWT access token in a 
> mode
>other than a bearer token?  For example is there a way to bind the JWT to a
>verifiable key or identifier.  If there is, there should be some 
> discussion of
>this in the security considerations.  If not, do the authors know if there 
> is
>any work planned in this area?
At this time, the main mechanisms that can work with non-bearer ATs are dPOP 
and MTLS. In both cases, the binding mechanism relies on a cnf claim (or 
reference to it) - which can be added to a JWT access token without changing 
any of the guidance in this specification. There's a quick primer for both 
approaches in https://auth0.com/blog/identity-unlocked-explained-episode-1/. 
Given that there are no changes in the AT format and verification, and 
MTLS/DPOP would be purely additive, any language here would likely be 
functionally equivalent to "You should be aware that MTLS exists, and the 
tokens defined here do not break it" (DPOP isn’t mentioned because it's still 
in progress) but my intuition is that the compatibility should be assumed, with 
a note being required when it's not the case and the reader should be aware of 
potential problems. What do you think?  


On 2/7/21, 10:48, "Joseph Salowey via Datatracker"  wrote:

Reviewer: Joseph Salowey
Review result: Has Issues

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is the document has issues.

1.  (Editorial) What is the relationship between this document and RFC 
7523. 
They are using JWT for different purposes, but I think it would be useful to
clarify this in the introduction.

2.  (Issue) The specification does not specify any mandatory to implement 
for
the recommended asymmetric algorithms.  This will not help interop.  Perhaps
specify one or both of  "RS256" and "ES256".

3. (Question) Is it currently possible to use the JWT access token in a mode
other than a bearer token?  For example is there a way to bind the JWT to a
verifiable key or identifier.  If there is, there should be some discussion 
of
this in the security considerations.  If not, do the authors know if there 
is
any work planned in this area?

4. Genart review pointed out a nit that should be fixed.




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

Re: [OAUTH-WG] Genart last call review of draft-ietf-oauth-access-token-jwt-11

[Vittorio Bertocci]

Thank you Roni,
Great catch! I made those two client_id values consistent, the change will 
appear in 12.
Thanks
V.


On 2/7/21, 01:28, "Roni Even via Datatracker"  wrote:

Reviewer: Roni Even
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-oauth-access-token-jwt-??
Reviewer: Roni Even
Review Date: 2021-02-07
IETF LC End Date: 2021-02-09
IESG Telechat date: Not scheduled for a telechat

Summary:
The document is ready for publication as a standard track RFC with nit

Major issues:

Minor issues:

Nits/editorial comments:
In section 3 the get example has client_id as s6BhdRkqt3 and the claims has 
s6BhdRkqt3_







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