Explict security target

[Nat Sakimura]

When writing security and privacy considerations, explicit security and privacy assumptions and target would definitely help. Right now, we have attacker models but we do not have these.

We probably should have it earlier. It would have made the formal verification easier. Now that security researchers are working on the formal model, perhaps we can just have a rough text on it and later replace it with what security researchers come up with.

One of the deficiencies of FAPI 1.0 is that we actually do not have spelt out the security assumptions and target. We should make sure that we do it in FAPI 2.0.

[Dave Tonge]

Is this not included in the attacker model?

[Nat Sakimura]

No, unfortunately.

[Daniel Fett]

What could an explicit security target that you have in mind look like?

[Tom Jones]

Interesting topic. OIDF has talked around targets a lot, public versus private clients, etc., but never defined any explicit target. That was intentional as it limits the scope of any standard. I doubt that OIDF really wants to be in this business, but in case that they do, here are some explicit targets.

1. docker container
2. smart phone native app with secure enclave access and biometric access control
3. smart phone web app

Before a Target Operations Model can be undertaken, the organizational model and data flow model must exist. See documents like NIST SP 800-171 as a place to start and get out your check book, this is expensive.

[Nat Sakimura]

I gathered that the attacker model document is laying out attacker models that all the FAPI 2 specs should assume and laying out common requirements/targets. The attacker model document states:

• FAPI 2.0 profiles shall ensure that no attacker can access resources belonging to a user.
• FAPI 2.0 profiles shall ensure that no attacker is able to log in at a client under the identity of a user.
• For authentication: FAPI 2.0 profiles shall 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 shall ensure that no attacker is able to force a user to use resources of the attacker.

This reads like it is a baseline/common requirement for all the drafts and has given me the impression that each FAPI 2 specs has something on top of it and thought that is missing in this document.

If that is not the case and the security target in the attacker model document is only meant for FAPI 2.0 Security profile (aka baseline), then, we may as well import the section from the attacker model.

With regard to it, I was also going to create another ticket to the attacker model document but it is related so I would write it here as well.

The attacker model document’s Security Goals section states “FAPI 2.0 profiles shall ensure … “ That’s a bit weird as it is not testable (nor achievable). I suppose it would be more appropriate if the attacker document’s security goals section was just explaining the desired properties that FAPI 2.0 profiles may want to utilize when writing. For example:

Authorization

AZ_1: A protocol is said to achieve authorization when an attacker acting as a client cannot access resources

belonging to a user with a probability significantly better than negligible.

The access token is the ultimate credential for access to resources inOAuth. Therefore, this security goal is fulfilled if no attacker cansuccessfully obtain and use an access token belonging to a user.

etc. and then in the Security profile document, have something like this in 4.1

The security goal of this document is as follows:

T1. FAPI 2.0 Seucrity profile protocol run fulfils AZ_1.

T2. FAPI 2.0 Security profile protocol run fulfils SS_1.

T3. In addition, when the user’s identity is seeked by the client, FAPI 2.0 Security profile protocol run fulfils AN_1.

T4. … (an additional security target for this document. Is there any?)

Thoughts?

‌

[Nat Sakimura]

Hey, @tomcjones, I was not talking about that kind of target. You are now talking about deployment target, I guess. Perhaps you can raise another issue regarding it.

[Tom Jones]

no @Nat, I don’t think that explicit targets belong in a protocol spec. I do agree that the expectations around the attacker model are wildly overblown. All they really say is that after an attack has be identified, it SHOULD be addressed. This the posture of the US CISA (aka US CERT) notices. These, of course, are updated every week, which standards cannot even aspire to.

[Nat Sakimura]

I guess there are privacy targets/goals like “only ephemeral identifiers are passed through the front channel from which it may leak without application-level encryption” as well.

[Nat Sakimura]

The cross-device document is relevant but is not sufficient.