Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-device-flow-11: Discuss
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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Let me preface this by noting that I'm not sure that all of these points are actionable; I would, however, like to discuss them. I'm really unhappy to not see any hard numbers on the entropy needed in a user code to provide a reasonable security margin with given parameters, and how it compares to the guessability bounds considered best practices in general (across protocols). For example, we think 128-bit symmetric keys are okay because an attacker has to put in 2**96 work to have a 2**-32 chance of guessing correctly via brute force; the rate limiting and finite lifetime on the user code places an artificial limit on the amount of work an attacker can "do", so if one uses a 8-character base-20 user code (with roughly 34.5 bits of entropy), the rate-limiting interval and validity period would need to only allow 5 attempts in order to get the same 2**-32 probability of success by random guessing. Section 5.1 would be a great place for such text, near the preexisting: The user code SHOULD have enough entropy that when combined with rate limiting and other mitigations makes a brute-force attack infeasible. We talk about "the authorization server", but any given *user* may have a relationship with multiple such ASes. Can the Introduction make it more clear that the AS is associated with the device/client, and as such the it may not be the user's most-trusted AS? It also seems like a large latent risk with this flow is when the verification_uri_complete response is used along with an AS that assumes an authenticated user making such a verification request has approved the authorization (i.e., without an explicit user interaction to confirm), when that AS uses cookies or other persistent state to keep the user authenticated across multiple requests. I could not find any MUST-level requirement for user interaction to confirm the device being authorized (even in Section 3.3, which covers the regular verificat_uri workflow!); please let me know if I missed something. I would like to see some explicit text that (matching the flow described in Section 3.1 that requires the user to input the code) explicit user approval of the authorization is required. (I do note that Section 5.3 has text about "SHOULD display information about the device.) I'm also unhappy about the text in Section 1 that merely requires of the device the ability to "make outbound HTTPS requests", which leaves room for an awful lot of sins in certificate validation (and, potentially, ciphersuite selection). Can we get a MUST-level requirement for authenticating the server and a cite to RFC 7525? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please use the RFC 8174 boilerplate instead of the RFC 2119 one. Section 3.2 The example expires in 30 minutes? That seems longer than needed; wouldn't 5 minutes do? Section 3.3 I agree with directorate reviewer that the MUST NOT requirement for displaying the device_code should justify that requirement by discussing the consequences of exposure. Section 3.5 authorization_pending The authorization request is still pending as the end-user hasn't yet completed the user interaction steps (Section 3.3). The client should repeat the Access Token Request to the token endpoint. I feel like we want to mention the 'interval' here or some other discussion of an inter-request delay. Also, please clarify "reasonable default polling interval", per multiple directorate reviews. Section 5.2 Please clarify the entities involved in "the backchannel flow" that can be MITM'd. Section 5.6 The "short-range" part of a "short-range wireless signal" partially depends on how big the receiver's antenna is. So perhaps we should be careful about indicating that this has more security value than it does. Section 6.1 I'm not sure I understand the usage of "case-insensitive", here -- how would the user have an expectation of case-insensitivity? Perhaps it is better to just say "majuscule" or "upper case" or whatever. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
