[Openid-specs-fapi] Working Group Last Call - FAPI 2 Security Profile - Final

Wed May 1 17:19:43 UTC 2024

I have reviewed this version of the document and I have the following
comments:

5.2.1. Requirements for all endpoints
NOTE 1: Even if an endpoint uses only organization validated (OV) or
extended validation (EV) TLS certificates, an attacker using rogue
domain-validated certificates is able to impersonate the endpoint and
conduct man-in-the-middle attacks. CAA records [RFC8659] help to mitigate
this risk.

[Rifaat] The above statement is suggesting that implementation should
consider implementing CAA records to avoid this attack. Why not explicitly
call that out, instead of mentioning this in a note?

5.2.2.2. MTLS ecosystems

MTLS ecosystems may implement MTLS to govern access to the ecosystem
independently from MTLS being used for client authentication or token
binding.

[Rifaat] I am not sure what this means. mTLS, as compared to TLS, is
essentially for client authentication. So, what is meant by “govern access”
beyond that?
[Rifaat] Is token binding an option?

MTLS ecosystems should provide the trust list of the certificate
authorities to ease integration, security and interoperability concenrs.

[Rifaat] Typo: concenrs -> concerns
[Rifaat] Is not that the default case? What is unique about FAPI 2.0?

5.3.2.1. General requirements

10. shall not use refresh token rotation unless, in the case a response
with a new refresh token is not received and stored by the client, retrying
the request (with the previous refresh token) will succeed;

[Rifaat] I am having a hard time digesting this paragraph. I am not sure
what it is trying to say.

14. to accommodate for clock offsets, shall accept JWTs with an iat or nbf
time up to 10 seconds in the future, however should reject JWTs with an iat
or nbf of 60 seconds or greater in the future.

[Rifaat] What should the AS do when iat/nbf is greater than 10 but less
than 60?

A pre-condition for this attack is that the attacker has control of an
authorization server that is trusted by the client to issue access tokens
for the target resource server. An attacker may obtain control of an
authorization server by:
1. compromising the security of a different authorization server that the
client trusts;
2. acting as an authorization server and establishing a trust relationship
with a client using social engineering; or
3. compromising the client.

[Rifaat] How would “compromising the client” allow the attacker to control
the authorization server?

Regards,
 Rifaat

On Tue, Apr 30, 2024 at 4:41 AM Dave Tonge via Openid-specs-fapi <
openid-specs-fapi at lists.openid.net> wrote:

> Dear FAPI Working Group
>
> In addition to the FAPI 2 Security Profile, we also want to take the FAPI
> 2 Attacker Model to final.
>
> This is a working group last call to review the document and raise any
> issues before we start the public review process for moving the
> specification to final.
>
> The document is available to review here:
> https://openid.bitbucket.io/fapi/fapi-2_0-attacker-model.html
>
> Please raise any issues before 06 May 2024.
>
> Thank you
>
> Dave Tonge
> FAPI WG Co-Chair
>
>
> On Wed, 24 Apr 2024 at 19:01, Dave Tonge <dave.tonge at momentumft.co.uk>
> wrote:
>
>> Dear FAPI Working Group
>>
>> We've resolved all remaining issues for the FAPI2 security profile -
>> thank you for all your help and input over the last few months (and years!)
>>
>> This is a working group last call to review the document and raise any
>> issues before we start the public review process for moving the
>> specification to final.
>>
>> The current working document is available here:
>> https://openid.bitbucket.io/fapi/fapi-2_0-security-profile.html
>>
>> Please raise any issues before 06 May, 2024.
>>
>> Thank you
>>
>> Dave Tonge
>> FAPI WG Co-Chair
>>
>>
>>
>>
>>
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
> Limited which is authorised and regulated by the Financial Conduct
> Authority ("FCA"). Moneyhub Financial Technology is entered on the
> Financial Services Register (FRN 809360) at https://register.fca.org.uk/.
> Moneyhub Financial Technology is registered in England & Wales, company
> registration number 06909772. Registered address: C/O Roxburgh Milkins
> Limited Merchants House North, Wapping Road, Bristol, United Kingdom, BS1
> 4RW, United Kingdom. Moneyhub Financial Technology Limited 2024 © Moneyhub
> Enterprise.
>
> DISCLAIMER: This email (including any attachments) is subject to
> copyright, and the information in it is confidential. Use of this email or
> of any information in it other than by the addressee is unauthorised and
> unlawful. Whilst reasonable efforts are made to ensure that any attachments
> are virus-free, it is the recipient's sole responsibility to scan all
> attachments for viruses. All calls and emails to and from this company may
> be monitored and recorded for legitimate purposes relating to this
> company's business. Any opinions expressed in this email (or in any
> attachments) are those of the author and do not necessarily represent the
> opinions of Moneyhub Financial Technology Limited or of any other group
> company.
>
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-fapi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20240501/2f447993/attachment.html>