more description of the security model

[Joseph Heenan]

As per discussion on https://bitbucket.org/openid/fapi/issues/150/mandate-at_hash-check-in-the-id-token-from it may be worth adding a description of the security model:

I wonder if we should explain the full security model somewhere, unless it's already covered somewhere else?

The way I see it there's a chain here where a weakness at any point could allow a rogue access token in:

discovery - protected by TLS cert, but I presume a client generally only fetches this once

jwks_uri - obtained from discovery, protected by TLS cert and refreshed frequently

id_token - validated by keys from jwks_uri

access token - validated by hash from id_token

That would tend to imply that we should make it clear that discovery & jwks_uri endpoints are both on a 'secure' server and (as Nat had suggested before) that people should look at techniques like TLS certificate pinning, DNSSEC, etc, etc.

It all depends on how far we want to go. e.g. openbanking neither recommend certificate pinning (at least as far as I can see in the security specification), and I believe all bank jwks uris are hosted on a host under openbanking.org.uk, and that domain doesn't appear to have DNSSEC setup.

[Daniel Fett]

I think that describing the attacker model (or the attacks the FAPI aims to prevent) in more detail is an important point. We(*) performed a formal analysis on FAPI based on a relatively strong attacker model that we derived from clues in the FAPI docs. Under these assumptions (among others, token endpoint can be misconfigured and auth request/response leak to an attacker), we found four attacks that have not been mitigated yet:

• The cuckoo's token attack: an attacker can inject a stolen access token into a FAPI flow under certain configurations. This is not mitigated by MTLS or OAUTB.
• Use of leaked access token: similar to above, an attacker can inject a stolen access token into a FAPI flow using a misconfigured token endpoint. This is not mitigated by MTLS or OAUTB.
• PKCE Chosen Challenge attack: an adversary that can observe the authorization response can use this to steal a code or token from a user.
• Leak of the state value: see issue #175

We sent details of these attacks to the authors listed in the drafts.

I think a clarification of the attacker model is needed in order to clarify against which of these attacks the FAPI tries to protect its users.

(*) Pedram Hosseyni performed the analysis as part of his master's thesis supervised by me at the University of Stuttgart

[Dave Tonge]

So I've started trying to document the attacker model. At a high level this is what I have so far:

Summary of attacker model:

• A1. Auth request leaks
• A2. Auth response leaks
• A3. Client / RO can be tricked into using a Bad RS
• A4. Access token leaks (e.g. at RS)
• A5. Client can be tricked into registering with Bad AS
• A6. Bad AS can trick Client into using Honest RS
• A7. Honest AS Token endpoint controlled by attacker
• A8. Attacker can get honest user to visit a page they control
• A9. Auth request tampered with
• A10. Auth response tampered with

Security Assumptions:

• S1. TLS is not broken
• S3. Honest AS Jwks_uri endpoint can not be controlled by attacker
• S4. Honest AS Discovery endpoint can not be controlled by attacker
• S5. Honest AS Authorization endpoint can not be controlled by attacker
• S6. JWS is not broken
• S7. HTTP POST requests and responses from the UA to the AS cannot be intercepted or tampered with

Most of the attacker model assumptions can be taken from RFC6819, RFC7636 and draft-ietf-oauth-security-topics. However A9 and A10 need further discussion. We mention them in FAPI Part 2 - 8.4. I think we need to better document the scenarios in which those attacks can occur and we need to do a thorough analysis to ensure that we protect against such attacks.

For example what are the situations where A9 and A10 are possible but where S7 is not possible?

Also is it worth protecting against A7 if we have to assume S3, S4 and S5? (the social engineering attack that leads to A7, could in theory lead to S3, S4 and S5). It may be better to provide security considerations to encourage protection against such attacks.

I'd be grateful for any input from the WG on this issue as soon as possible.

For background I recommend this slide deck: https://sec.uni-stuttgart.de/media/events/osw2019/slides/hosseyni-_formal-analysis-fapi.pdf and this paper https://arxiv.org/pdf/1901.11520.pdf

Many thanks to Daniel, Pedram and Torsten for their work in this area.

[Joseph Heenan]

Thanks Dave!

S4. Honest AS Discovery endpoint can not be controlled by attacker

Probably an aside at this stage, but does this mean FAPI should be requiring that AS / client use discovery? (and probably some related clause that the discovery endpoint should be hosted on the AS etc.)

I similarly agree about A7 vs S3-S5.

S1: Does that mean there's no flaws in the cryptography / implementation of the protocol? Do we need a separate point to cover "Attacker cannot obtain a TLS certificate acceptable to the UA covering the AS hostname"?

For example what are the situations where A9 and A10 are possible but where S7 is not possible?

I think there probably are some - the browser URL bar and (say) transferring auth requests/responses around a mobile OSes url launching system mean there's potentially more points these can be tampered with, whilst interfering with S7 requires fuller access to the browser given S1.

[Dave Tonge]

I don't think FAPI needs to require discovery. I just think we need to make it clear to implementers that the manner in which the Client obtains the AS metadata is vital to protect. We could suggest that discovery (when implemented properly) would reduce the social engineering attack vector.

Do we need a separate point to cover "Attacker cannot obtain a TLS certificate acceptable to the UA covering the AS hostname"?

Yeah I think we should expand on the TLS / PKI / DNS assumptions we are making.

the browser URL bar and (say) transferring auth requests/responses around a mobile OSes url launching system mean there's potentially more points these can be tampered with

Thanks Joseph that is a helpful distinction. Have you heard about any such tampering either as a proof of concept or as an actual attack?

[Daniel Fett]

Thanks Dave!

I think it might help to closely align this attacker model and the one in the security BCP. Currently, it is hard to compare the two models. This is my take on that:

(this attacker model) -> (security BCP)

• A1 -> A4
• A2 -> A3
• A3 -> A5
• A4 -> stronger version of A5?
• A5 -> follows from A1
• A6 -> follows from A1
• A7 -> not contained in security BCP
• A8 -> A1
• A9 -> not contained in security BCP (although leakage might lead to a replay of the authorization request with tampered contents)
• A10 -> not contained in security BCP

As far as I can see, the security assumptions are roughly the same.

In any case, the attacker in the FAPI model MUST be as strong or stronger than the one in the Security BCP model.

I propose that we try to base the FAPI model on the Security BCP model and describe where the FAPI attacker model is stronger than the Security BCP model (and why). This can also mean to make attacks in the security BCP more explicit (like A5, A6).

What do you think?

[Joseph Heenan]

Thanks Joseph that is a helpful distinction. Have you heard about any such tampering either as a proof of concept or as an actual attack?

The use of custom url schemes allows interception, which is why we disallow them. The app stores / mobile OSes did not prevent more than one app claiming a custom url scheme. https://www.blackhat.com/us-16/briefings.html#crippling-https-with-unholy-pac is a real attack that leaks urls, albeit one I hope is mitigated in browsers/OSes these days. Interception of urls in the browser history has historically been an issue and one of the attacks mitigated by the hybrid flow returning the authorization code in the url fragment, but there's currently no similar mitigation to stop the authorization request leaking I believe.

[Joseph Heenan]

(None of these explicitly allow tampering, but my gut feeling is that once you've intercepted, tampering isn't a huge leap, especially in attacks where the UA loading both the original request and then the temperated request works fine.)

[Dave Tonge]

Thanks Daniel and Joseph.

I've adjusted the model, so that it is inline with the Security BCP.

From the Security BCP:

• A1 -> Attackers can trick RO into visiting a page they control, Clients can be tricked into registering with bad AS, Bad AS can trick Client into using its tokens with honest RS.
• A2 -> Attackers have full control of all network communication NOT protected by TLS
• A3 -> The Authorisation Response can leak, but not be tampered with (a tampered version could be replayed)
• A4 -> The Authorisation Request can leak, but not be tampered with (a tampered version could be replayed)
• A5 -> Attacker can control honest RS and therefore obtain valid access tokens

The attacker model is extended from this by:

• A6 -> Auth request can be tampered with
• A7 -> Auth response can be tampered with
• A8 -> Honest AS Token endpoint controlled by attacker

We assume the following:

• S1. TLS is not broken
• S2. Honest AS Jwks_uri endpoint can not be controlled by attacker
• S3. Honest AS Discovery endpoint can not be controlled by attacker
• S4. Honest AS Authorization endpoint can not be controlled by attacker
• S5. JWS is not broken
• S6. HTTP POST requests and responses from the UA to the AS cannot be intercepted or tampered with

[Tom Jones]

The correct terminology (from a threat mode perspective) is not "we assume the following:" but rather "Accepted Risks" Peace ..tom

[Pedram Hosseyni]

Hi Dave,

In my view, A6 and A7 should be more specific on the MITM. Currently, this sounds like a network attacker, for which it (here) is sufficient to use TLS. As I understood the discussions at the OSW, the FAPI want to protect against a MITM which can read the messages in the clear and modify them, right?

How realistic are S2, S3, and S4 if "the client developer is social engineered into believing that the token endpoint has changed to the URL that is controlled by the attacker. " [FAPI2, 8.3.2]?

In the FAPI, A5 is considered only in the RW profile, and accordingly, nothing is done against AT leakage in the RO profile. (In the RW profile, it is assumed that the AT is somehow phished, so the assumption that a RS is controlled by the attacker is not necessary). I also do not see how the use of a leaked AT in the RO profile can be prevented without adding more mechanism to bind the AT to the client. I can see, though, that the current attacker model is aimed at the RW Profile, however, the RO Profile is currently not as secure as required by the BCP.

[Dave Tonge]

Re-opening this issue, as we discussed on the call that it would be good to get this sorted before we change the name.

Attacker Model

This is a summary of the Attacker model described in the Security BCP (https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/?include_text=1)

• A1 -> Attackers can trick RO into visiting a page they control, Clients can be tricked into registering with bad AS, Bad AS can trick Client into using its tokens with honest RS.
• A2 -> Attackers have full control of all network communication NOT protected by TLS
• A3 -> The Authorisation Response can leak, but not be tampered with (a tampered version could be replayed)
• A4 -> The Authorisation Request can leak, but not be tampered with (a tampered version could be replayed)
• A5 -> Attacker can obtain valid access tokens (either through taking control of an honest RS or other means)

In this WG we have looked at an extended attacker model:

‌

• A6 -> Auth request can be tampered with though the OS or Browser
• A7 -> Auth response can be tampered with through the OS or Browser
• A8 -> Honest AS Token endpoint controlled by attacker

We assume the following:

• S1. TLS is not broken
• S2. Honest AS Jwks_uri endpoint can not be controlled by attacker
• S3. Honest AS Discovery endpoint can not be controlled by attacker
• S4. Honest AS Authorization endpoint can not be controlled by attacker
• S5. JWS is not broken
• S6. HTTP POST requests and responses from the UA to the AS cannot be intercepted or tampered with

Currently the Read only profile can protect against A1 - A4, whereas the Read/Write profile can protect against A1 - A8.

There are potential issues with the assumptions S2,S3 and S4 - these probably need to be dealt with by security considerations as I think its impossible to fully protect against them.

It would be good to get some feedback on this, thanks.

[Stuart Low]

Regarding:

S1. TLS is not broken

Can this be assumed? By way of example the ACDS uses a centrally issued CA MTLS certificate for resource server interactions but the IdP is protected by public certificate authority certificates out of necessity to facilitate end user browser sessions.

Observationally at least there seems to be a reasonable expectation that even if TLS for IdP interactions (protected by public CA) is compromised that tokens are not disclosed or at least the chance is lowered (for instance if there has been data collection occurring as well).

EDIT: A better example here is perhaps that it is assumed within ACDS that MTLS may be terminated at an OPs border but there is a desire to secure the token content through to an organisations IdP software perhaps multiple levels deep (and transited via various means) within the network topology. Ie. limit exposure to bad internal actor attack.

I believe this is a primary reason for ACDS using encrypted ID tokens, essentially as a mitigation to exposure to the public CA trust space and as a way of continuing to secure token content even after TLS is unwrapped.

‌

[Tom Jones]

Remind me again as to the justification of using an attacker model instead of the traditional threat model? It seems like the comments are reasons why a more traditional model would be better.

[Daniel Fett]

See https://bitbucket.org/openid/fapi/issues/175/clarify-attacker-model-pkce-method-and#comment-50416522

[Tom Jones]

Neither that thread, or this addresses new challenge created by app-app interactions. I am building those and am convinced that fapi has not addressed this new environment with analysis of existing environments.

[Joseph Heenan]

Can you explain a bit more about the new challenges please Tom?

If this is using OAuth2/OpenID Connect between mobile apps, I wrote about the model ( https://josephheenan.blogspot.com/2019/08/implementing-app-to-app-authorisation.html ) and [other than a slight difference to the trust placed in the OS related to correctly verify claimed https urls] I didn’t identify anything that change the attack model. If anything I’d say it has some positive security aspects compared to doing the same operations in a web browser.

[Daniel Fett]

I see no reason why this cannot be covered by an attacker model. We just need to figure out which, if any, changes need to be made.

[Dave Tonge]

Stuart - its a good point re TLS and attacks that happen between the device terminating TLS and the app server. We probably should consider it as it is a valid attack vector. It would be interesting to work out if we could still protect in part 2 if TLS is broken. However its difficult because if TLS is broken then we can’t rely on the RP or OPs JWKS endpoints and therefore signing is useless as well.

[Tom Jones]

From the other thread - the right solution IMHO is to require JWS with a well-known root of trust. If we add JWE there is no added value from TLS required.

[Stuart Low]

@Dave Tonge So for ACDS at least encrypted tokens are mandated (where as part 2 specifies it MAY be if memory serves correctly?). The attack vector, particularly the one involving compromise of transmission post TLS tunnel unwrap, was raised by multiple participants so it seems like at least some risk departments classify it as a reasonable risk.

@Tom Jones The consideration here plays in when the device terminating the TLS (like a border firewall/waf etc) is not the same as the IdP itself especially when considering these devices may be managed by separate departments within an organisation. Personally I’m of the opinion that it’s important FAPI remains secure potentially in the absence of assumed TLS, hence I asked the question in the beginning on whether the presence of TLS is a valid assumption.

With that said, the comment regarding JWKS endpoints potentially being compromised negating these protections is definitely valid, I suspect this may not have been fully considered by participants although multiple security layer principles doesn’t negate it.

[Tom Jones]

This thread is really odd. Discovery is not required but jkws is not to be trusted? The first would fix the second.

‌

[Dave Tonge]

Tom we’re trying to nail down what attack vectors we want the two FAPI profiles to protect against. Once we’ve agreed on the attack vectors we then need to analyse the spec to ensure that it does indeed protect against these vectors.

[Daniel Fett]

What attacks/attackers are we talking about?

As a basis for this discussion, I created a cheat sheet with all currently known, important kinds of attacks on OAuth/OIDC that target the protocol itself, not individual errors in implementations: https://docs.google.com/spreadsheets/d/1PtG4f-Svils7wHBa7cGaZubbh-6lGifce38c_oShSss/edit?usp=sharing
Note that the numbering of the attackers is slightly different than in this thread. Please also note that the attack descriptions are kept very brief. Please refer to the documents linked to get a full picture of the attacks.

Observations

The current FAPI attacker model, which is implied by the chosen defense mechanisms in Parts 1 and 2 and some comments in these documents, is based on Attackers A1 to A9. This is a very strong attacker model - good! Most of the attackers are reasonable to assume as well. A5, A6, and A9 are probably the strongest ones and it might be worth to discuss their practical relevance.

However, not all attacks are currently prevented in FAPI, see column Q in the table. Except for a variant of the PKCE Chosen Challenge attack that I presented at IETF 105, fixes exist and can be incorporated into future versions of FAPI (see the respective issues in this bug tracker).

It is interesting to note that Part 1 covers almost as many attacks as Part 2 does. (Some of the attacks are easier to execute.) → Do we really need public clients?

Non-repudiation is a topic that is somewhat different to other attacks: Non-repudiation is needed to ensure that parties cannot deny having sent a specific message.

Future Attacker Model

I propose that we change the two profiles to the following:

Baseline Profile

(For bikeshedding, please follow this link.)

• Uses the same strong attacker model (A1-A9) that FAPI currently uses, but makes it explicit.
• For baseline, in the following tree, remove everything except for the rightmost path (keeping JARM and, if needed, Hybrid flow, and of course use PKCE everywhere). Then add whatever is needed to defend against the known attacks. (A formal analysis can then evaluate if we did everything right.)

Advanced Profile

• Uses the same attacker model plus the requirements for non-repudiation.
• Created by adding message signatures where they are not needed for baseline security.

‌

[Dave Tonge]

Thanks Daniel, this is incredibly helpful.

‌

[Torsten Lodderstedt]

We need to document our assumptions, e.g.

• TLS is not broken
• JWKS endpoints are not tampered
• …

‌

[Daniel Fett]

Good point, Torsten. Just like the attackers, this should be made more explicit. I will work on that.

[Daniel Fett]

In preparation for today’s call I updated the description of the assumptions, of non-repudiation requirements, and other parts of the attack cheat sheet at https://docs.google.com/spreadsheets/d/1PtG4f-Svils7wHBa7cGaZubbh-6lGifce38c_oShSss/edit?usp=sharing

I’d also like to update my recommendation for the two new profiles:

Baseline Profile

• Uses the same strong attacker model (A1-A8) from the cheat sheet, which equates to the one currently implicitly used by FAPI. (Note: Numbering of the attackers changed in the meantime.)
• Avoid usage of application-level signatures (except for the ID token), i.e., no JAR or JARM; my impression is that we can reach the security goals without any of these
• Use PAR and code flow with PKCE
• No token binding

PAR ensures integrity of the authorization request to avoid mix-ups, some forms of CSRF attacks, a form of the PKCE Chosen Challenge attack, and other attacks (see cheat sheet).

An open question is whether the compromised token endpoint (attackers A5 and A6 in the cheat sheet) are potentially too strong: They might yield attacks that are hard to mount in practice, yet require major changes in the protocol to defend against. I suggest to leave this question open until we have a deeper understanding of what the new FAPI profiles can deliver in terms of security and then decide whether to exclude these attackers or introduce new protection mechanisms.

Advanced Profile

• Provides, on top of the Baseline Profile, non-repudiation via JAR and JARM (NR1 and NR2 in the cheat sheet)
• Signed introspection/userinfo responses (NR4 and NR5)
• We can also think about signed requests to and responses from the resource endpoints (NR6 and NR7)

When complete, this profile then provides non-repudiation on the whole protocol.

‌

[Torsten Lodderstedt]

I assume the baseline profile would use mTLS or DPoP to implement sender-constrained access tokens

[Torsten Lodderstedt]

The Advanced Profile should include ID Tokens as detached signature to achieve backward compatibility.

[Tom Jones]

The following is not a security consideration, it is an accepted risk. Switching to application level from network level would all the weird problems . mTLS seems out-of-place in a multi-rooted trust model unless you mean that all host must have a common root of trust. While UKOBIE may spec that, i don’t believe openID does.

In any case - please justify this as a baseline “security” requirement. It sounds more like an accepted risk that is mitigated by network security features.

Avoid usage of application-level signatures (except for the ID token), i.e., no JAR or JARM; my impression is that we can reach the security goals without any of these

[Daniel Fett]

That is not a security requirement, but a design recommendation. Whether or not we can do away with application-level signatures in the baseline profile depends on whether we can achieve the security goals without them.

What do you mean by “all host must have a common root of trust”? The authorization servers? The clients? What is the problem with mTLS exactly?

[Tom Jones]

Mtls offers no value if the provinance of the cert cannot be digitally determined. You do understand, I hope, that Google no longer relies on certificate provinance. Perhaps you should talk to Ryan Hurst at Google. BTW, Ryan used to own mtls for Windows at the time I owned crypto for Windows.

[Daniel Fett]

In PSD2, for example, clients are authenticated using eIDAS QWACs from a defined list of issuers. In other contexts, pre-registered client certificates are used. I see no problems with either method for client authentication.

Apart from that, we also need mTLS for sender-constraining access tokens.

[Tom Jones]

I have done client auth for 25 years. I believe your first statement to be unrealistically optimistic.

You second statement is false. There are lots of better ways to bind a token to a sender.

[Daniel Fett]

Proposal for the two new profiles:

https://docs.google.com/document/d/1Lo2LCV5eV7iVGbsM0C7i3pL1nWRftfqjpfFCx5Q3Pds/edit?usp=sharing

[Daniel Fett]

We have a documentation of the attacker model in FAPI 2.0 now. I don’t expect that we backport that into 1.0. Can we close the issue?

[Dave Tonge]

Closing this issue as it is being address in FAPI 2.0