[secdir] secdir review of draft-ietf-oauth-device-flow

"Christopher Wood" <christopherwood07@gmail.com> Wed, 13 June 2018 00:55 UTC

Return-Path: <christopherwood07@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A255130DC5; Tue, 12 Jun 2018 17:55:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9z9XhhQYqn0O; Tue, 12 Jun 2018 17:55:36 -0700 (PDT)
Received: from mail-pl0-x242.google.com (mail-pl0-x242.google.com [IPv6:2607:f8b0:400e:c01::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AC7A12F1AB; Tue, 12 Jun 2018 17:55:33 -0700 (PDT)
Received: by mail-pl0-x242.google.com with SMTP id b14-v6so474655pls.5; Tue, 12 Jun 2018 17:55:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=Z1cnwK4VlGFflP8D+7Y6CyCFpZrskj0p4WkQSzjQ7/o=; b=FxrQx6DrikWx8eCzoZJqhDFtM3slIdWqlsgFq5//byvvru37VXA9LeQpEUosxMEZuD hSL2mf3jbqHtF9nLFMXrfgSCBr2a7FuGgJ7nhPbKOlJMit27aJVbLG8FoqvsQBQWeTXz ppo39FlaX/DcbHiL8QVigAFiPGih7q2NYVlZN922sJhEcSMcePsrLqeQPSGFQUeqERpl BoMlRDHHxzu0dDl7eSwK2zD/R5JRNEi7t65fz7HKiSZdkXFMzjaVilWAdpvzC9aYqTPZ rPfV8ks+8uqwJgxtBkdSqKBhbIL+0l29KKyyGV4LGKl6PAaxiYaQvN4ESI0KgFjdRzRb Xj4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=Z1cnwK4VlGFflP8D+7Y6CyCFpZrskj0p4WkQSzjQ7/o=; b=H5THf5NVwjEDBOY9shefYeE2wAIdukg/WXRYKTk0YpweiesHqdmyvktjfIH5NgOBxN Qw4jFHtX9S4hx361zzc/mRpC3BTNkjUzN86oNgre0kc5TfA+ghOA4/O+MkpsXL9kUZE/ 2Hynjy1fNruGtBMe7hGfLJUypuZpX1pDIijNKJUQwW7bjQmaB7G0aWC7fp41TVXWHPgC d3dxQRgaijzFOJi5/MgBiHMHJ/S/K24GcANCU9NTi7/IX1nCeyFvqoAWuWdlF8SZJYkm W7ymCNffCDgQb61uBpn1Mx6/Ij2aeHTg+R3m20sqpoTt54fuvsnEVLEcv0VK2TKpVD3C SUxA==
X-Gm-Message-State: APt69E1c1KH7VEjryQBvEjfDaZLWXBgVL6dlEGsFLANillNQ2dckmzKk dCCAmAxqzztHrdtB+heqwB7Zsidm
X-Google-Smtp-Source: ADUXVKL9o/CnjI1V3Hjlxc7btC1ue3D6HTQIb1sV1Vk68gSNS2AedFLhhYMvIwdMpf6XhIjQm5xnGw==
X-Received: by 2002:a17:902:145:: with SMTP id 63-v6mr2783807plb.332.1528851332355; Tue, 12 Jun 2018 17:55:32 -0700 (PDT)
Received: from [10.132.58.100] ([66.155.106.22]) by smtp.gmail.com with ESMTPSA id l8-v6sm1931544pfb.102.2018.06.12.17.55.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jun 2018 17:55:31 -0700 (PDT)
From: "Christopher Wood" <christopherwood07@gmail.com>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-oauth-device-flow.all@ietf.org
Date: Tue, 12 Jun 2018 17:55:22 -0700
X-Mailer: MailMate (1.11.2r5479)
Message-ID: <E17D37F9-070C-4E9D-9955-0E50F09DA89B@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/qTh4jySqySdVZx3dXIx9DFbkaSU>
Subject: [secdir] secdir review of draft-ietf-oauth-device-flow
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jun 2018 00:55:38 -0000

Hello,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

   The summary of my review is: Ready with nits.

Overall, the document is in fine shape. I have a few general comments 
(not quite nits,
though not quite issues either), listed below:

- Section 3.5, fifth paragraph: Requiring clients to poll at a 
“reasonable” polling interval
without a suggestion of what is reasonable seems strange. Could you 
suggest a value that’s
within reason, e.g., every second?
- Section 5.1, first paragraph: It might be useful to point to Section 
6.1 wherein User Code
generation is discussed. Right now minimum entropy “requirements” 
are listed without further
details regarding viable mechanisms.
- Section 5.2, second paragraph: The text claims that an end user would 
end up “on the
authorization page of the wrong service.” Can you provide more details 
here? What stops
the malicious MITM from serving an authorization page that’s 
indistinguishable from the
legitimate service page?
- Section 5.3, first paragraph: How specifically does the authorization 
service prevent
devices from lying when providing “information about the device”? 
Or, alternatively, how
does the authorization service learn this information?
- Section 5.4: Would it be useful to suggest that clients SHOULD use a 
secure (encrypted
and authenticated) channel when communicating to the user device?

The remainder of my comments, listed below, are editorial in nature, 
aimed towards improving
readability of the document.

- Section 1, step (E): This is the first time client polling is 
mentioned without
discussion of timeouts or server-generated errors. The draft provides 
such details later
on, so it would be helpful to allude or point to them here.
- Section 3.3, second paragraph: Please cite TLS upon use (“… in a 
secure TLS-protected
session.”).
- Section 3.3, second paragraph: The text suggests that the server 
informs the user to
“return to their device.” Perhaps this should be prefaced with a 
MAY, as the client will
eventually learn that authorization is complete upon polling.
- Section 3.3.1, first paragraph: Should it be required that 
“verification_uri_complete”
is constructed in part from the “verification_uri” and 
“user_code”? I’m not sure this is
necessary, though the example given is constructed this way. If not 
required, this might be
worth noting.
- Section 3.5, first paragraph: s/token endpoint/authentication server?
- Section 5.1, third paragraph: This text is mostly redundant with the 
preceding paragraphs.
I would remove or merge it with the paragraphs above.

Please let me know if you’ve further questions, comments, or concerns. 
I hope this helps.

Best,
Chris