Provide commentary on any requirements layered on the OAuth threat model

findthomas commented 13 years ago

Provide commentary on any requirements layered on the forthcoming OAuth security considerations section; discuss UMA-layer implications for more meaningful authentication of requesters/requesting parties; discuss implications of user-mediated AM/host trust model; discuss short-lived token technique for lightweight requester correlation... (Someone want to take this AI?)

[Previously #18]

xmlgrrl commented 12 years ago

Assigned to Rich Goodwin and George Fletcher.

xmlgrrl commented 12 years ago

Here are some thoughts on draft-ietf-oauth-v2-threatmodel-06, which was published on 27 Jun 2012 (http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-06):

General: Most of this threatmodel applies to UMA as well, particularly the OAuth-specific flows that involve PATs and AATs. The notes that follow try to identify new or extended security considerations.

Sec 2.1: List of items out of scope:

For OAuth, communication between AS and RS is out of scope, but UMA puts it in scope by defining specific flows between them for a certain loosely coupled set of use cases. So that bullet item doesn't apply to UMA.
Would "clients not bound to a specific deployment" be in scope for UMA, in a way that it's not in scope for OAuth? I'm fuzzy on this item as stated here.
General thoughts on scope: Should we put the choice of UMA claim profile out of scope? What about the choice of token profile?

Sec 2.2: Attack assumptions:

UMA would have to assume that the attacker may have access to communication between the AS and RS, unlike OAuth.
(General question:) Does the assumption that the attacker has unlimited resources put proof-of-work countermeasures out of reach?

Sec 2.3: Architectural assumptions: We have some of these types of assumptions in our charter, as part of our design principles. So our own security considerations text should mention those.

Sec 2.3.1: AM: Our AM (similar to OAuth's AS) would store the equivalents to the listed items, including authorizing user credentials (= user names and passwords), host and requester client credentials (two sets vs. OAuth's one), host and requester client-specific refresh and access tokens (ditto), and RPTs (new).

Sec 2.3.2: RS: Our host would have to store its own client credentials and refresh and access tokens to use at the AM, along with the other items listed.

Sec 2.3.3: Client: Hmm. We would probably want to break out this series of sections into AM (extended AS), host (has aspects of RS and also client), and requester (has "normal" client aspects).

Sec 3.1: Tokens: We'd have to discuss PATs, AATs, and RPTs, along with the rest.

Sec 3.1.1: Scope:

We'd need to discuss resource sets, scopes, permissions, and other authorization data. Perhaps this can be stolen from explanatory text we already have.
The mention that "A scope is typically complemented by a restriction on a token's lifetime" is something that we have a bit of non-normative commentary about in the core spec; maybe we can move or copy it to UMA's security considerations.

Sec 3.6: Does UMA need a state parameter for RPTs? We don't currently have one (we just have one for claims-gathering flows, which is different).

Sec 3.7: client identifier:

The discussion about using the client identifier to display relevant registration information to a user has an analog in UMA: The resource set information that a host registers with an AM, causing the AM to retrieve data at the supplied URIs. Any threats here need to be documented in UMA's security considerations.
Regarding the two client types, confidential and public, is it the case that UMA hosts are always confidential? Should we state this to be so, by fiat? (Where the OAuth text says that "the latter is considered more secure", is this a typo? Should it be "the former" (confidential clients)?)

Sec 4: Threats: UMA needs to go through a process of identifying and documenting additional threats, attacks, and countermeasures on top of OAuth, considering:

Host as client
Host as resource server
Requester as client
AM as protection API server
AM as authorization API server
Requesting party (which operates outside of the requester app when it comes to claims-gathering flows)
Authorizing user? (what happens if they're malicious? any threats?)

Further, does it make sense to look at all the same components through the eyes of privacy considerations, looking for direct exposure to "too much information" and also inappropriate opportunities to correlate identities?

xmlgrrl commented 11 years ago

Domenico's comments from 10 Dec 2012:

here are my first comments about OAuth threat model applied to UMA spec.

On top of OAuth spec, UMA provides more scenarios, including person-to-person and person-to-org interactions, where the Requester (Client) interact with the host on behalf of the user which isn't the resource owner.
In these contexts, for the "implicit flow" (4.4.2), where the redirect URI includes the access token in the URI fragment, the protocol can be exposed to threat, including leaking of tokens. For example, considering Alice as Authorizing User who defines a policy for sharing a resource with users (Requesting Party), which have > 18yo. A malicious user, (let's say Bob who is 18 years old) which is authorized to access to a resource, can obtains the tokens and share it with unauthorized users (under 18).

Are the bearer tokens suffice in this case?

In the UMA spec, do we need to explicit the use of "status" and "redirect_uri" parameters into the request format? These two parameters are fundamental as countermeasures against threats respectively for phishing attacks and Cross-Site Request Forgery (CSRF) attacks. We have defined these parameters for UMA OpenID claim profile.