Mohamed Boucadair has entered the following ballot position for draft-ietf-oauth-cross-device-security-14: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi Pieter, Daniel, and Filip, Thank you for the effort put into this document. Thanks to Bing Liu for the OPSDIR review and to the authors for engaging and the PR. This is a well-written and easy-to-read document, although there are some repetitions here and there. Please find below some comments (ordered following the doc flow). I will send you a PR for some nits I tagged when reading. # Target Abstract: It serves as a security guide to system designers, architects, product managers, security specialists, fraud analysts and engineers implementing cross-device flows. I understand this is not an exhaustive list, but given that the guidance also recommendations for service providers and users, I thought that these are better listed here as well. # Beyond OAUTH WG CURRENT: This section describes the set of security mechanisms and measures to secure cross-device protocols against Cross-Device Consent Phishing and Cross-Device Session Phishing attacks that the OAuth working group considers best practices at the time of writing this specification. Once approved, this will reflect the IETF consensus, not only this specific WG I suggest to reword accordingly. # Implementers What is meant by “implementers” in Section 2? Is this the “service providers” mentioned in the discussion sections? Else? # Implement with risk CURRENT: 2. Implementers SHOULD avoid cross-device flows if risks cannot be sufficiently mitigated. Should there by a companion recommendation to encourage flagging/disclosing the unmitigated risk for user awareness? # Same-device scenarios CURRENT: Cross-device protocols SHOULD NOT be used for same-device scenarios. If the Consumption Device and Authorization Device are the same device, protocols like OpenID Connect Core [OpenID.Core] and OAuth 2.0 Authorization Code Grant as defined in [RFC6749] are more appropriate. The background sections didn’t mention the same-device case. The introduction and use of “Cross” hint that target devices are distinct. You may elaborate this part early in the document. # Same-device/Channel CURRENT: the mitigations recommended in this document SHOULD be implemented to reduce the risks that the unauthenticated channel is exploited. I’m not sure to understand this case. Which channel are we referring to here if these are the same device? # Privacy considerations CURRENT: Note that the authorization server typically cannot directly determine whether the Consumption Device and Authorization Device are physically close to each other. Instead, it must rely on the surrounding systems, protocols in use, device capabilities, or information it obtains from other systems to establish or verify proximity. Some of the mitigations have implications on privacy (tracking locations, user fingerprinting, etc.). The trade-off between privacy vs intended benefit should be called out. # Efficiency CURRENT: The authorization server can validate information it receives, but it cannot independently measure or enforce proximity on its own. An attacker can also present (fake) location information that can be misleading for authorization server. Unless there is a mean to attest the authenticity of presented data, trusting this data for driving the authorization server behavior may lead to suboptimal behavior. BTW, almost all the listed alternatives for proximity matters do not guarantee the outcome, while others depend on the user setup (e.g., NFC/BLE activation). # Risk profile CURRENT: Depending on the risk profile and the threat model in which a system is operating, it MAY be necessary to use more than one mechanism to establish proximity to raise the bar for any potential attackers. ## What is “risk profile”? Who is supposed to do that risk assessment? ## How is this reco different from this one provided earlier? It is RECOMMENDED that one or more of the mitigations be applied when implementing a cross-device flow. # What risk? CURRENT: There is no guarantee that the primary and secondary holders are in the same location at the time of the authorization. In such cases, proximity (or lack of proximity) may be an indicator of risk and the system may deploy additional controls (e.g., transaction value limits, transaction velocity limits) or use the proximity information as input to a risk management system. How is this a risk? Proximity checks can even be a hindrance to the service in such a case. # Why isn’t this a reco? CURRENT: If an authorization server determines that a user code or QR code is being used in an attack it may choose to invalidate all tokens issued in response to these codes and make that information available through a token introspection endpoint (see [RFC7662]). The document uses MAY as a reco for similar discussions in other sections. Why is this not a reco (i.e., use MAY as in other sections)? # Trusted Networks Note sure if this is useful to be mentioned in that section, but there are cases where SIM-based checks are used as trusted network. Cellular operators may provide APIs for such checks. # Prevent CURRENT: The practical mitigations described in this section can prevent the attacks from being initiated, … It seems to me that none of the mitigations completely nullify the risks. At best, they can contribute to soften them. Maybe “prevent” is not accurate here, or at least, I would explain what is meant. # Security Considerations CURRENT: Security considerations are described in Section 2 and Section 6. I’m afraid this needs some elaboration to reflect implications of some proposed mitigations. For example, Click here to grant access to your files. If you are not trying to access your files, you should decline this request and notify the security department"). opens the door for a variety of attacks. There are security issues with clickable links per se that are worth to be highlighted. Cheers, Med _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
