Document: draft-ietf-oauth-cross-device-security Title: Cross-Device Flows: Security Best Current Practice Reviewer: Jim Fenton Review result: Almost Ready
Document: draft-ietf-oauth-cross-device-security-13 Title: Cross-Device Flows: Security Best Current Practice Reviewer: Jim Fenton Review result: Almost ready I am the designated ARTART reviewer for draft-ietf-oauth-cross-device-security. I found the document to be clearly written and generally well organized. Some specific comments: In the context of authentication, so-called "authentication fatigue" attacks have become very common where the attacker pesters the victim with many requests to approve an authentication request until they get tired and approve one of them to make the annoyance go away. I would expect that to be at least as prevalent for some of the cross-device authorization flows because the push request is not always preceded by single-factor authentication. I didn't see much discussion of this attack except perhaps in 4.3.4. On the other hand, Section 1.1 paragraph 2 refers to "[the user] accept[ing] an authorization request pushed to their Authorization Device", which makes it seem like all they need to do is press "accept" rather than transfer a user code. Example A4 (Section 3.3.4) also seems particularly vulnerable to fatigue attacks. Section 3 deals with both authorization and session transfer, but the introductory paragraph specifically describes session transfer. Section 3.1 has two references to an Authentication Device, while elsewhere the term Authorization Device is used everywhere. I didn't dig into the underlying specifications to see if it's described there, but I'm not clear on how the Authorization Server is located. For example, if I want to authorize the TV in my hotel room to display some content from my tablet, how do I find that server? Download the <hotel chain> app, perhaps, and enter my "6 digit" code there? It's probably clearer for QR codes that might have a URL. On a related note, the specification leans heavily on the user code being 6 digits or so. Whether that's sufficient depends heavily on the scope of the authorization server. You need enough digits not to authorize the wrong thing by mistake, especially in the absence of a proximity check. I didn't see this discussed. There is also probably a related attack where attackers guess user codes. Several of the flow diagrams have bidirectional arrows for steps that are logically unidirectional. For example, the diagram in Sections 3.1.2 and 3.1.3 have bidirectional arrows for (E) Grant Authorization, while it really goes from the Authorization Server to the Consumption Device, not the other way. There are a number of similar instances. Section 4.1, talking about the ability of the attacker to chance the context of the authorization request, perhaps note that this is possible also because the request is unsigned. In Section 6, some of the mitigations (e.g., Shared network) "bury the lede" by describing a possible mitigation in detail with only a brief mention of the problems associated with it. Some of the mitigations have definite deployment or effectiveness limitations. Section 6.1.7, device types seem easily spoofable. Section 6.1.15, many phishing-resistant authenticators (e.g., FIDO) require registration prior to use. It's not clear how authenticating first would be accomplished for many of the use cases described. A forward reference from 6.1.1 "Wireless proximity" to Section 6.2.3 might be helpful. In Section 6.2.3, FIDO2/WebAuthn is an authentication protocol that requires advance registration to authenticate, and therefore would not fit many of the example scenarios. What's perhaps needed is a subset of the hybrid authentication protocol that uses BLE to establish proximity in conjunction with a user code or QR code. I don't think that's spelled out anywhere, however. Security Considerations seems a little thin for a document focused primarily on security. There were a few typos and grammatical errors. I can provide the ones I saw to the authors on request. _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
