marcopernpruner
commented
1 year ago You can find below the list of mitigations extracted from draft-ietf-oauth-cross-device-security, together with our suggested status (mandatory/recommended/not recommended/not applicable) and some considerations for the IT Wallet scenario.
CC: @fmarino-ipzs, @giadas
| ID | Mitigation | Status | Entity | Notes |
|---|---|---|---|---|
| C1a | Establish Proximity (Physical connectivity) | Not recommended | - | Due to the significant worsening of the usability level. |
| C1b | Establish Proximity (Wireless proximity) | Not recommended | - | Due to the significant worsening of the usability level. |
| C1c | Establish Proximity (Shared network) | Not recommended | - | Due to the significant worsening of the usability level. |
| C1d | Establish Proximity (Geo-location) | Not recommended | - | Due to the low precision of the geo-location procedure. |
| C2 | Short Lived/Timebound QR or User Codes | Mandatory | Verifier | Reducing the lifetime of the QR code is fundamental to restrict the time window available for the attacks. We suggest a time interval of 2-3 minutes (as in "Entra con CIE"). |
| C3 | One-Time or Limited Use Codes | Mandatory | Verifier | One-Time QR codes restrict the possibility of attacks when the same QR code is sent to multiple victims. We mandate One-Time instead of Limited QR codes. |
| C4 | Unique Codes | Mandatory | Verifier | Represents a prerequisite for C3. Issuing unique QR codes allows the Verifier to detect if the same codes are being repeatedly submitted. As the QR code is composed of multiple parameters, the uniqueness is not given only by the identifier, but by the whole set of parameters. |
| C5 | Content Filtering | Not applicable | - | Techniques suggested by this mitigation (e.g., spam filters) are out of scope with respect to the Verifier. |
| C6 | Detect and Remediate | Not applicable | - | Invalidating tokens is not effective in our scenario, as the VP token can be only used one time. This mitigation is needed in case of authorization with access/refresh tokens. |
| C7 | Trusted Devices | Mandatory | Verifier | There are no guarantees on the device that initiates the protocol (i.e., the personal computer). Citizens must be able to initiate the protocol from any device. However, we still mandate the restriction of the use of older browsers and OSs. Moreover, we suggest avoiding the execution of JavaScript scripts (if possible). |
| C8 | Trusted Networks | Not applicable | - | Citizens must be able to initiate the protocol from any network. |
| C9 | Limited Scopes | Not applicable | - | This mitigation specifically refers to access tokens. |
| C10 | Short Lived Tokens | Recommended | Wallet and/or Verifier | It specifically refers to access and refresh tokens, but can be applied to VP tokens by checking the iat or exp parameters. Therefore, either: (i) the Wallet sets a short expiration time (exp); or (ii) the Verifier checks the iat parameter based on a custom policy for token duration. |
| C11 | Rate Limits | Mandatory | Verifier | The Verifier must limit the request for multiple codes by the same entity in a limited interval of time to prevent attackers from obtaining (and sending) multiple QR codes. |
| C12 | Sender-Constrained Tokens | Not applicable | - | It specifically refers to access and refresh tokens. |
| C13/C14 | User Education/Experience | Recommended | Wallet and Verifier | Makes users aware of the ongoing operations and the risks of scanning QR codes from untrusted sources, to prevent illegitimate approvals. |
| C15 | Authenticated Flow | Recommended | Verifier | If a Verifier has a custom, phishing-resistant authentication method, we suggest using it before starting the presentation so that the QR code can be linked to the authenticated User. It is part of the Verifier's responsibility to ask the Wallet to include in the VP Token the identifier information to be verified. |
| C16 | Request Initiation Verification | Recommended | Wallet and Verifier | Requires users to transfer an OTP from the Wallet to the Verifier. |
| C17 | Request Binding with Out-of-Band Data | Recommended [alternative to C15] | Verifier | Before initiating the flow, requires users to insert an identifier information that will be inserted in the QR code to restrict the attack surface. It is part of the Verifier's responsibility to ask the Wallet to include in the VP Token the identifier information to be verified. |
grausof
peppelinux
According to https://datatracker.ietf.org/doc/html/draft-ietf-oauth-cross-device-security
We need to compare the current solution and get the best from the BCP