Security goals requirements ("shalls") may need to be relaxed/reworded

[Nat Sakimura]

Currently, it goes like this:

FAPI 2.0 profiles shall ensure that no attacker can access resources belonging to a user.

This probably is unachievable because

• it is only a probabilistic thing after all; and
• a spec cannot ensure bad implementation does not happen.

Perhaps we can relax wording a bit like “attacker cannot access resources belonging to a user with a probability significantly better than negligible” instead of “no attacker can”. Maybe am I too pedantic?

Also, instead of mandating a document, it might be better to just to define the security property like “Authentication” here and move the security goals to each specific document. This will make it possible to define “non-repudiation” within the security goals instead of having an independent clause later.

Alternatively, it can be reworded in the following manner as well:

FAPI 2.0 profiles shall formally verify that no attacker can acess resources belonging to a user

In this case, it is clear that “no one” within the verification model and whether it was formally verified is testable.

‌

[Dave Tonge]

@Daniel Fett do you have a view on this?

[Daniel Fett]

I think we should reword as follows:

• “FAPI 2.0 profiles aim to ensure that no attacker can access resources belonging to a user.”
• I would have to check again if we don’t say this already, but we should make clear that the profiles can cover whatever happens on the protocol layer.
• The profiles also make assumptions about browser, server and infrastructure behavior. This behavior can change over time, leading to new security problems.
• Same for bad implementations.

I don’t think we should say “with a probability significantly better than negligible” because that only aims at guessing random numbers and encrypted values. We want to cover more than that (especially things happening on lower or higher layers of the stack).

I’ll prepare a PR.

‌

[Daniel Fett]

PR in https://bitbucket.org/openid/fapi/pull-requests/358/improve-description-of-attacker-model

Note: As suggested by Nat, I moved the non-repudiation goals into the advanced spec.

[Nat Sakimura]

The construct “(this document) shall (mandates)” is a bit weird. A document cannot be mandated of anything.

Perhaps we can just define security properties, e.g., Authorization etc. in this document, and then state:

The security goal of the FAPI 2.0 Security Profile is to fulfil Authorization, Authentication, and Session Integrity.

etc.

In addition, for “Authorization” property, I have a concern about the statement “belonging to a user”. What we are after here is to prevent a party from accessing the protected resource without fulfilling the policy set forth by the resource owner, and it does not matter if the resource “belongs to a user” or not, are we not?

‌

‌

[Dave Tonge]

change “shall aim…” to “aims…”

[Daniel Fett]

Reword to Fix Issue #508

→ <<cset b8861d2571f1>>

[Nat Sakimura]

Merged in danielfett/fapi/fix-508 (pull request #382)

Reword to Fix Issue #508

Approved-by: Joseph Heenan Approved-by: Nat Sakimura

→ <<cset 849eb9c59559>>