%%% title = "FAPI 2.0 Attacker Model" abbrev = "fapi-2_0-attacker-model" ipr = "trust200902" workgroup = "connect" keyword = ["security", "openid"]
[seriesInfo] name = "Internet-Draft" value = "fapi-2_0-attacker-model-00" status = "standard"
[[author]] initials="D." surname="Fett" fullname="Daniel Fett" organization="yes.com" [author.address] email = "[email protected]"
%%%
.# Abstract
OIDF FAPI 2.0 is an API security profile suitable for high-security applications based on the OAuth 2.0 Authorization Framework [@!RFC6749]. This document describes that attacker model that informs the decisions on security mechanisms employed by the FAPI security profiles.
{mainmatter}
Since OIDF FAPI aims at providing an API protection profile for high-risk scenarios, clearly defined security requirements are indispensable. In this document, the security requirements are expressed through attacker models, security goals, and non-repudiation requirements. From these requirements, the utilized security mechanisms are derived in the Baseline and Advanced profiles.
The ultimate aim is to provide systematic proofs of the security of the FAPI profiles similar to those in [@arXiv.1901.11520]. Such proofs can rule out large classes of attacks rooted in the logic of security protocols. The security requirements in this document are therefore expressed in a form that lends itself well to a transfer into a formal representation required for an automated or manual analysis of the security of FAPI. This work draws from the attacker model and security goals formulated in [@arXiv.1901.11520].
This document is not an OIDF International Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an International Standard.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.
The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.
The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
FAPI 2.0 profiles aim to achieve at least the following security goals (with respect to the attacker models defined below):
FAPI 2.0 profiles MUST ensure that no attacker can access resources belonging to a user.
The access token is the ultimate credential for access to resources in OAuth. Therefore, this security goal is fulfilled if no attacker can successfully obtain and use an access token belonging to a user.
FAPI 2.0 profiles MUST ensure that no attacker is able to log in at a client under the identity of a user.
The ID token is the credential for authentication in OpenID Connect. This security goal therefore is fulfilled if no attacker can obtain and use an ID token carrying the identity of a user for login.
Session Integrity is concerned with attacks where a user is tricked into logging in under the attacker’s identity or inadvertently using the resources of the attacker instead of the user’s own resources. Attacks in this field include CSRF attacks (traditionally defended against by using “state” in OAuth) and session swapping attacks.
In detail:
- For authentication: FAPI 2.0 profiles MUST ensure that no attacker is able to force a user to be logged in under the identity of the attacker.
- For authorization: FAPI 2.0 profiles MUST ensure that no attacker is able to force a user to use resources of the attacker.
This attacker model assumes that certain parts of the infrastructure are working correctly. Failures in these parts likely lead to attacks that are out of the scope of this attacker model and MUST be considered and analyzed separately.
For example, if a major flaw in TLS was found that undermines data integrity in TLS connections, a network attacker (A2, below) would be able to compromise practically all OAuth and OpenID Connect sessions in various ways. This would be fatal, as even application-level signing and encryption is based on key distribution via TLS connections.
The following parts of the infrastructure are out of the scope of this attacker model:
- TLS: It is assumed that TLS connections are not broken, i.e., data integrity and confidentiality are ensured. The correct public keys are used to establish connections and private keys are not known to attackers (except for explicitly compromised parties). Exceptions are A6 and A9, where an attacker compromises a TLS terminating endpoint.
- JWKS: Where applicable, key distribution mechanisms work as intended, i.e., encryption and signature verification keys of uncompromised parties are retrieved from the correct endpoints.
- Browsers and Endpoints: Except for A4a and A4b, devices and browsers used by resource owners are not compromised. Other endpoints not controlled by an attacker behave according to the protocol.
FAPI 2.0 profiles aim to ensure the security goals listed above for arbitrary combinations of the following attackers:
Standard web attacker model. Can send and receive messages just like any other party controlling one or more endpoints on the internet. Can participate in protocols flows as a normal user. Can use arbitrary tools (e.g., browser developer tools, custom software, local interception proxies) on their own endpoints to tamper with messages and assemble new messages. Can send links to honest users that are then visited by these users. This means that the web attacker has the ability to cause arbitrary authorization requests from users' browsers, as long as the contents are known to the attacker.
Cannot intercept or block messages sent between other parties, and cannot break cryptography unless the attacker has learned the respective decryption keys. Deviating from the common web attacker model, A1 cannot play the role of a legitimate AS in the ecosystem (see A1a).
Like the web attacker A1, but can also participate as an AS in the ecosystem. Note that this AS can reuse/replay messages it has received from honest ASs and can send users to endpoints of honest ASs.
Controls the whole network (like a rogue WiFi access point or a nation-state sponsored hacker). Can intercept, block, and tamper with messages intended for other people, but cannot break cryptography unless the attacker has learned the respective decryption keys.
Note: Most attacks that are exclusive to this kind of attacker can be defended against by using transport layer protection like TLS.
Note: The attackers for the authorization request are more fine-grained than those for the token endpoint and resource endpoint, since these messages pass through the complex environment of the user's browser/app/OS with a larger attack surface. This demands for a more fine-grained analysis.
The capabilities of the web attacker, but can also read the authorization request. This might happen on mobile operating systems (where apps can register for URLs), on all operating systems through the browser history, or due to Cross-Site Scripting on the AS. There have been cases where anti-virus software intercepts TLS connections and stores/analyzes URLs.
The capabilities of the web attacker, but can also read the authorization response. This can happen e.g., due to the URL leaking in proxy logs, web browser logs, web browser history, or on mobile operating systems.
This attacker makes the client use a token endpoint that is not the one of the honest AS. This attacker can read and tamper with messages sent to and from this token endpoint that the client thinks as of an honest AS.
The capabilities of the web attacker, but this attacker can also read requests sent to and from the resource server, for example because the attacker can read TLS intercepting proxy logs on the RS's side.
The capabilities of A7, but this attacker can also tamper with responses from the resource servers (e.g., a fully compromised resource server).
Beyond what is captured by the security goals and the attacker model, parties could try to deny having sent a particular message, for example, a payment request. For this purpose, non-repudiation is needed. This is achieved by providing application-level signatures that can be stored together with the payload and meaningful metadata of a request or response.
- NR1: Authorization Requests
- NR2: Authorization Responses
- NR3: ID Token Contents
- NR4: Introspection Responses
- NR5: Userinfo Responses
- NR6: Resource Requests
- NR7: Resource Responses
{backmatter}
<title>OpenID Connect Core 1.0 incorporating errata set 1</title> NRI Ping Identity Microsoft Google Salesforce<title>An Extensive Formal Security Analysis of the OpenID Financial-grade API</title>