[secdir] Secdir review of draft-ietf-oauth-spop-11

Ben Laurie <benl@google.com> Fri, 05 June 2015 12:44 UTC

Return-Path: <benl@google.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED6A1B2EF5 for <secdir@ietfa.amsl.com>; Fri, 5 Jun 2015 05:44:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level:
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 oqHR-VkekkzX for <secdir@ietfa.amsl.com>; Fri, 5 Jun 2015 05:44:41 -0700 (PDT)
Received: from mail-vn0-x22a.google.com (mail-vn0-x22a.google.com [IPv6:2607:f8b0:400c:c0f::22a]) (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 B08D01B2EFE for <secdir@ietf.org>; Fri, 5 Jun 2015 05:44:40 -0700 (PDT)
Received: by vnbg1 with SMTP id g1so8818534vnb.3 for <secdir@ietf.org>; Fri, 05 Jun 2015 05:44:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ykUJDztPorE4bnD4JaDFpumIIy3wP+ZXedLfrX8avdI=; b=hxyqeV2XFYehdqGyavOlA4fdhbjrV4TRSJy7f4cMjtTXqF06iyD49Kj/MKCy0vOwok ioKhZDd2/JwtLV3VAeut7iH5hf5dlttLPLdVgbXcwl5lDJ1wfhgdU2EbArz2yXj7Dkn3 t5kyylZRtlnWExn+M8T5Sv3Rk/8ht27cQDJ+zfxEmeWJ5S9oRp5r2YvPkiGrEDuQzkpj q40G/Jf5hoc19gvn1NrUo4GgqEWdvSiYi56YxvKp7/y8RTm55PeUveKo3eJOWxSCo7HB BAyxzZJkpY+4BMqfdIRzD4NDxGzfE0y3ZGdvLqoeccoiF4/6er+OSqyttl+4K4AcDIpx EMDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=ykUJDztPorE4bnD4JaDFpumIIy3wP+ZXedLfrX8avdI=; b=Cv4fcVSTjvXxSPBc6uvAPAM5LuNQKoqmSR/UWESz8WBXLXjo1+goJQtt49PYlsvMOu eiO9zsDi3moCZQ9Hw2bZFwTKB1HEr4ELhxCYcHb9hZGMs8SmcYDUkrpqn6mKahxCk/NF 7qerD1hiSsdvJ4s007e9FFmmUhHw4vQavYe6kxGvH8e7IHurn1VLpziNosY764Vq5Kx6 RvBo+rPOQgmJ1Ckrllao3XrHuXG0sYtu7/E+9fpFC/HjZPEHjJNEMbC1lnu6CYmc2A0u 7JwHmVw/mOvJQ+3wdeEklUvT/51DmBrN/PD6AyUXTQHAZEJpX8OU6xUsHpZQxjhofUVR 0PVw==
X-Gm-Message-State: ALoCoQkb9djt/z4p/pxozSEXfJEsMIVaKg9vCrHMPWwp3EUbommSbrpZ13aj1czkxQeQKOGAiX5d
MIME-Version: 1.0
X-Received: by 10.52.75.201 with SMTP id e9mr5767020vdw.33.1433508279791; Fri, 05 Jun 2015 05:44:39 -0700 (PDT)
Received: by 10.52.76.6 with HTTP; Fri, 5 Jun 2015 05:44:39 -0700 (PDT)
Date: Fri, 05 Jun 2015 13:44:39 +0100
Message-ID: <CABrd9SQ68C1j3sax73mEmkZCgxgQZtB6=L8m6aDR-fj9yF1kyw@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-oauth-spop.all@tools.ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/sOieke1LrDXGTBJFoUyqXLhDlR8>
Subject: [secdir] Secdir review of draft-ietf-oauth-spop-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Fri, 05 Jun 2015 12:44:43 -0000

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.

Status: ready with issues.

It is disappointing that such a protocol must be introduced to work
around security deficiencies in application platforms - have these
security issues been reported to vendors?

Anyway, issues:

1. Security consideration says: "Concatenating a publicly known value
to a code_challenge
   (with 256 bits of entropy) and then hashing it with SHA256 would
   actually reduce the entropy in the resulting code_verifier making it
   easier for an attacker to brute force." This makes no sense. A
brute force attack would still require iteration of 2^256 inputs. How
is that easier?

2. The introduction says "No client secret is used (since public
clients cannot keep their secrets confidential.)". However, a client
secret is used. I suspect I know what is intended, but this should be
clarified.