Clarify attacker model (PKCE method and CSRF protection)

[Daniel Fett]

The Read-Only profile of the FAPI requires the use of PKCE (Section 5.2.2, Number 7 of Draft-05). While there are two code challenge methods defined in PKCE (either "plain" or "S256"), the FAPI requires the use of "S256", where the underlying assumption is that the authorization request leaks due to "leaking http log information in the OS" (Pre-Condition 4b of RFC 7636).

Does the FAPI aim to protect against authorization request leaks?

If yes, then how is the leakage of the state value contained in the authorization request mitigated? As described in OAuth (Section 4.1.1 of RFC 6749), the state value should be used for preventing CSRF attacks.

In Section 5.2.3 of the Read-Only profile of the FAPI, the client is required to "implement an effective CSRF protection". How can this be achieved in a way suitable for all configurations, e.g., also for native app clients, when assuming that the authorization request leaks?

If no (i.e., PKCE is only used for code-injection protection), then why is the more complex S256 chosen, where the plain method would work fine?

[Dave Tonge]

Thanks Daniel. This is an interesting point. Isn't S256 almost required by PKCE though:

If the client is capable of using "S256", it MUST use "S256", as "S256" is Mandatory To Implement (MTI) on the server.

Re CSRF protection - I may be missing something, but aren't same-origin cookies fine for browser user agents? Native apps are usually inherently stateful and will have many ways of storing a reference to the session. So long as the CSRF is implemented correctly it shouldn't matter if the state leaks?

[Daniel Fett]

Yes, the implementation of S256 on the server is required by PKCE. My question was more about the assumptions the FAPI makes about the attacker.

CSRF protection for the redirection endpoint cannot be achieved by same-site cookies (which I guess you are referring to), since the request to the redirection endpoint is essentially an intended CSRF which is permitted from the IDP but must not come from an adversary. The state value is the only effective method for protecting against CSRF in this case. (A certain usage pattern of token binding might be able to replace the state value, but that is a different topic.)

[Dave Tonge]

So with regards to the assumptions about the attacker, I think this is definitely worth expanding on.

Re CSRF, sure I understand you now, just to make sure we are on the same page, the attack you refer to is:

• User makes legitimate authorization request
• Attacker gets access to state param in legitimate auth request via logs or similar
• Attacker crafts malicious authorization request, authenticates and gets back code
• Attacker causes user to issue a request to the redirect_uri with the malicious code but the legitimate state
• Client swaps malicious code for token and associates attackers resources with users session

i.e as described here https://tools.ietf.org/html/rfc6749#section-10.12

I think it would be good to discuss the attacker model on the next call.

[Daniel Fett]

That is the attack I had in mind, yes.

Note that the state can leak through various other ways as well, for example, through the referer header that is sent when the AS includes external resources (e.g., from a CDN) on its login page.

[Nat Sakimura]

Need to update on this before final.

[Tom Jones]

There is a deeply flawed assumption here that needs to be dispelled. That is that if the known attacks are all mitigated, that the protocol is then secure. That is not the way that threat modeling works. The canonical method for creating a threat model is that the data flow diagram is examined with known techniques to determine where weak spots exists. This technique does not work well with openID specs because there are so many options that it is not clear that all of the potential implementation's data flow diagrams are fully comprehended. The idea of "attacker model" is flawed. It seems to imply that all attacks are known, which is empirically false. The reason that i am sure of this problem is that i started a threat modeling exercise on OIDC and found the fundamental problem of evaluating a standard with so many options. I suspect that the value of the Fett paper mentioned in another thread will be found to be incomplete for the same reason.

This note is not meant to dispute Nat's comment, which is perfectly valid. Know attacks should always be addressed. Just don't assume that mitigation of known attacks is a positive statement of security.

[Dave Tonge]

Hi Tom

I fully agree that we shouldn't "assume that mitigation of known attacks is a positive statement of security.".

I think the aim here is to better document the assumptions we are making about what an attacker can or can't do. We have these assumptions, but we need to do a better job of documenting them.

Of course the assumptions may be wrong, but it is still better to document them.

[Tom Jones]

That is exactly the view that i am trying to tell you will not work. The attackers will not be limited by your model, they will look for weaknesses that you have not considered. In fact the model may help them to find attack points. Please not try to build an attacker model, it will actual blind you to the attacks not considered.

[Daniel Fett]

Hi Tom,

I can see where you are coming from. What you are thinking about is the "classic" threat modeling approach. In this context, your statements are correct, and to avoid confusion we might think about calling the attacker model a "minimal attacker model" here. Nonetheless, as Dave wrote, we must make the attacker model consistent and well-documented. Let me explain:

What we do in our paper is a systematic formal analysis. This approach is relatively new in the web world, but similar methods are the de-facto standard for cryptographic protocols and have also greatly helped with designing and securing TLS 1.3.

In this formal approach, we use a model of a system (here: the web, including browsers, DNS, etc.) together with a model for attackers (here: network and web attackers) and we try to prove that no attacks are possible in this model. That is, if the proof is done correctly, we will have found all attacks that are theoretically possible in this model.

There are a number of advantages here:

1. We can find attacks that nobody has thought of, and even new classes of attacks. We do not need to be creative for this, the attack just pops up during the analysis. For example, we did not expect to find the mix-up attack or the 307 redirect attack on OAuth. Before we found these attacks, OAuth had been analyzed many, many times before, but not with a systematic formal approach.
2. Within the limits of the model, we can prove the security of a standard like the FAPI, i.e., the absence of any attacks that can be captured in the model. This already excludes large classes of attacks. In this case for example, I am very confident that we did not overlook any logic flaws in the protocol itself.
3. As you said, "The canonical method for creating a threat model [...] does not work well with openID specs". That is exactly why we need formal methods: In a formal approach, we can indeed reason about all the options in the FAPI.
4. Even just designing a formal model, formal security properties, and an attacker model greatly helps with finding flaws and inconsistencies in the specifications. That is why we created this issue we are discussing here in the first place.

If you are interested, I recommend reading [1], where we go into more detail of our web model and the analysis technique.

Our formal approach needs an attacker model that captures what the FAPI wants to defend against (and what not). Of course, attackers will have more power in the real world. And of course, implementations will almost always contain more bugs than we can possibly model. That is why complementary methods, such as classic threat modeling, are needed as well, in particular for the resulting implementations.

[1] https://sec.uni-stuttgart.de/_media/publications/Fett-PhDThesis-2018.pdf

[Tom Jones]

Any method that finds vulnerabilities is good.

Methods that find vulnerabilities are not, however, evidence of a robust, secure solution. I would point to implementations of of ukob that permit two applications running on the user's phone communicating with each other as one example. It is the user's money, but the two apps are not known to protect the money, only to protect themselves. Consider the case that the attacker is the client (or the op). That will be the attack as soon as wide deployment of "alternate" banks is available.

[Daniel Fett]

The formal analysis actually can provide you with evidence of a secure solution.

I do not get the point of what you describe next. Do you want us to consider malicious OPs or Clients? That is actually contained in our analysis...

[Joseph Heenan]

@tomcjones

I would point to implementations of of ukob that permit two applications running on the user's phone communicating with each other as one example. It is the user's money, but the two apps are not known to protect the money, only to protect themselves. Consider the case that the attacker is the client (or the op). That will be the attack as soon as wide deployment of "alternate" banks is available.

Can you expand more on this please Tom?

The situation is that there are two apps, both of which are first party apps, one belonging to the bank and the other to an authorised and regulated third party; both have legal duties to the protect the money and the user's data. The interactions between the apps follow the OpenID Connect standard for a normal redirect flow. The apps are acting as user agents for back end services. When the user is sent to the bank's app, they (the user) have to authorise the access/payment being made within the context of the bank's apps, in a similar way to if they were just initiating a payment themselves directly using the bank's app. The interaction between the apps is done with claimed https redirects where the OS has verified the link between the app and the website the bank intended to redirect back to.

Given that in the OBUK ecosystem the identity of the third party (ie. the RP) is heavily verified and shown to the user within the bank's app, it's hard to see the change in the attack model here.

In other ecosystems where the identity of the third party is not so well known this may give rise to weaknesses, but I also can't currently see how the use of the above app2app flow (vs a standard web based redirect flow on a desktop) increases the risk.

[Tom Jones]

You ask a lot of questions there. Let's focus on the use of app-app authn.

The design of openID connect contemplates the use of the user's browser as the "user agent" to display a UX as to whether the user gives consent to information sharing. Like most of the openID specs, this feature is optional. But when user consent via a user selected browser is not enabled, the user has no control over what data the op passes to the client. In the case where app-app authn and information sharing is enabled, the user is dependent on the app that wants the user's money (typically the client) and the app that has the user's money (typically the OP, altho other options are open for this as well) can send and honor a payment requests without any "messy confusing UX", very efficient, very dangerous. As Ralph has indicated in previous reports, there is an expectation of a lot of "innovation" in security UX. Innovative UX can be extremely confusing to a user. A lot of the justification for ukob leans heavily on the good behavior of the client and the OP. A lot of the justification for ukob and psd is the reduction of friction. I am very skeptical that his will work out well for the consumer. For a history lesson for those that have not been around long i suggest reading this paper by ross anderson https://www.cl.cam.ac.uk/~rja14/Papers/wcf.html

This is a quote from that paper.

In some countries (including the USA), the banks have to carry the risks associated with new technology. Following a legal precedent, in which a bank customer's word that she had not made a withdrawal was found to outweigh the banks' experts' word that she must have done [JC], the US Federal Reserve passed regulations which require banks to refund all disputed transactions unless they can prove fraud by the customer [E]. This has led to some minor abuse - misrepresentations by customers are estimated to cost the average US bank about $15,000 a year [W2] - but it has helped promote the development of security technologies such as cryptology and video.

In Britain, the regulators and courts have not yet been so demanding, and despite a parliamentary commission of enquiry which found that the PIN system was insecure [J1], bankers simply deny that their systems are ever at fault. Customers who complain about debits on their accounts for which they were not responsible - so-called `phantom withdrawals' - are told that they are lying, or mistaken, or that they must have been defrauded by their friends or relatives.

[Joseph Heenan]

But when user consent via a user selected browser is not enabled, the user has no control over what data the op passes to the client.

Can you explain the different in the control the user has between the app2app and web based redirection flows please? I'm struggling to see the difference, given in both cases the majority of the information exchanged between the RP and OP is done over the backchannel and not via the app / browser.

[Tom Jones]

When the user has a chance to see the consent request at the initiation of any relationship with a new client, there is a better chance that they will detect a relationship that they do not want to initiate. So while i might be willing to allow amazon to establish a billing relationship with my bank, i am less likely to allow a Russian controlled front company in Malta to do the same. As i read the PSD documents it seems to require EU banks to treat the two the same way.

[Joseph Heenan]

When the user has a chance to see the consent request at the initiation of any relationship with a new client, there is a better chance that they will detect a relationship that they do not want to initiate.

App2app flows require user consent at the OP side in exactly the same way as redirect based web flows. ("innovation" is equally possible in both flows.)

So while i might be willing to allow amazon to establish a billing relationship with my bank, i am less likely to allow a Russian controlled front company in Malta to do the same. As i read the PSD documents it seems to require EU banks to treat the two the same way.

The banks have to treat them the same, yes (pretty much; the risk based exemption for SCA may be more likely to be applied to Amazon than to a Russian company for various reasons). This is the same between the app2app flow and the web based redirection flows.

[Tom Jones]

You seem to be missing a critical distinction here. When the user agent is the browser, that is the display of the consent dialog from the OP. When the user agent is the Russian backed company in Malta, it is the display of the consent dialog. (You may object here, but the standard does allow this which means that someone will do it.) You seem to be pretty sanguine about letting some bureaucrat or software architect paid by the client to decide what i will see from the client rather than a relationship between me and my bank. I would be slightly more trusting of innovation at my bank than at the client. Sorry, but i have less comfort in that situation than you.

Getting back to the point of the thread. Standardization of attacker models will not detect innovative attacks. Traditional threat modeling has a much better (altho not perfect) chance of doing that.

[Joseph Heenan]

You seem to be missing a critical distinction here. When the user agent is the browser, that is the display of the consent dialog from the OP. When the user agent is the Russian backed company in Malta, it is the display of the consent dialog.

That distinction doesn't exist. The display of "do you want to let this third party access your data" dialog from the OP is done in the OP's app, NOT the Russian app.

ie. in the normal web redirect based flow, it is displayed in the "bank's web app" in the user's browser. In the app2app flow, the equivalent dialog is displayed in the "bank's mobile app".

[Tom Jones]

where, exactly, is the spec that describes that?

[Joseph Heenan]

https://www.openbanking.org.uk/wp-content/uploads/Customer-Experience-Guidelines-V1-1.pdf page 47 is probably closest, but it's almost certainly also an early version of this document that caused the confusion - to expand on two points:

1) This document covers app2app and web based; they are essentially identical (eg. compare pages 16 and 17)

2) Permission is granted to both the TPP and the bank in these flows; in this document (and much of OB/PSD2) it uses 'consent' for the permission given to the TPP to request/process the data and 'authorisation' for the permission for the bank to share the data with the third party. There's a fair bit of subtly in the difference that has earned a lot of billable hours for a lot of lawyers, but importantly (to the current conversation of whether app2app introduces new issues) it is the same on the web and app2app, and in both cases the bank asks the user what accounts they want to give the named 3rd party access to.

[Tom Jones]

let me know what that becomes a draft standard and i will comment then. Until then i will tell every one i can that app2app communications is insecure. I know something of that as i am building them.

[Joseph Heenan]

My understanding is the document is final; it's what the CMA9 OpenBanking UK banks have to comply with by the end of next month.

In terms of technical standards, it is standard open id connect with asymmetric client auth, signed request objects (and the other extra security requirements FAPI places on openid) and standard redirect flows, there's no changes at the protocol level.

[Nat Sakimura]

The Read-Only profile of the FAPI requires the use of PKCE (Section 5.2.2, Number 7 of Draft-05). While there are two code challenge methods defined in PKCE (either "plain" or "S256"), the FAPI requires the use of "S256", where the underlying assumption is that the authorization request leaks due to "leaking http log information in the OS" (Pre-Condition 4b of RFC 7636).

Does the FAPI aim to protect against authorization request leaks?

If yes, then how is the leakage of the state value contained in the authorization request mitigated? As described in OAuth (Section 4.1.1 of RFC 6749), the state value should be used for preventing CSRF attacks.

In Section 5.2.3 of the Read-Only profile of the FAPI, the client is required to "implement an effective CSRF protection". How can this be achieved in a way suitable for all configurations, e.g., also for native app clients, when assuming that the authorization request leaks?

If no (i.e., PKCE is only used for code-injection protection), then why is the more complex S256 chosen, where the plain method would work fine?

[Dave Tonge]

Just a note to say that I’m working on this and aim to have some proposed text by next week

[Dave Tonge]

Closing issue as it is being dealt with in 2.0