[OAUTH-WG] Security considerations in draft-sakimura-oauth-tcse-03

Josh Mandel <jmandel@gmail.com> Wed, 14 May 2014 23:43 UTC

Return-Path: <jmandel@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 94A721A0376 for <oauth@ietfa.amsl.com>; Wed, 14 May 2014 16:43:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JqJWBL5o9LzD for <oauth@ietfa.amsl.com>; Wed, 14 May 2014 16:43:11 -0700 (PDT)
Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7401A038E for <oauth@ietf.org>; Wed, 14 May 2014 16:43:10 -0700 (PDT)
Received: by mail-ob0-f172.google.com with SMTP id wp18so341106obc.3 for <oauth@ietf.org>; Wed, 14 May 2014 16:43:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=57C9lF/7QHOoSfxaDrAm+NqxNM4NxdiCNlFPy0vKI9k=; b=d2vVqDe4N9IZUk5p3c2CQefWPIXU4/vuycT0sHL9T2KJsaOi60T6Mb6urc8npuibro uk4TOO3aa98juOK/T0WwUKJoT4ziQbrkJABK1k8VEvKsMOqVj2dxQg4RdajcaV4vIEKi KbNyEYWvw6WlMVN65OT/UXfVYFGmOhuVp6uY5BbD4Dr7WKVLT6iDk22XbfdfnGFLKm5r PvkyUnfP9ulaabKaNHl66c8TU+w/fO7JUpkYkD7quiG19FKsXYPVgcGrvOf+drJusUHt ENjG2StohHdM3a5iO+OxWAX60NsSaDHsuzV3zrtUvzgv3ymp6tcPWwOc6hiAZPV4O9d5 Fojg==
MIME-Version: 1.0
X-Received: by with SMTP id ux5mr6695363obc.12.1400110983766; Wed, 14 May 2014 16:43:03 -0700 (PDT)
Received: by with HTTP; Wed, 14 May 2014 16:43:03 -0700 (PDT)
Received: by with HTTP; Wed, 14 May 2014 16:43:03 -0700 (PDT)
Date: Wed, 14 May 2014 16:43:03 -0700
Message-ID: <CANSMLKE3io952U0gCm2PS-yLSyFDWAWdjq2J=Fz2mwd9tY8=UA@mail.gmail.com>
From: Josh Mandel <jmandel@gmail.com>
To: "oauth@ietf.org WG" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c2e9ccd56c3004f964bd54"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/LW9Ff_6IYgkAnWvHfieXa51SJJY
Subject: [OAUTH-WG] Security considerations in draft-sakimura-oauth-tcse-03
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 23:43:12 -0000

Forgive me if this is well-trodden territory, but I would have expected the
security considerations in this proposal to include a note to the effect of:

"In a scenario where a mobile client is contending with malicious apps on
the same device that listen on the same custom URL scheme, it's important
to keep in mind that a malicious app can initiate its own authorization
request. Such a request  would appear the same as a legitimate request from
the end-user's perspective. So in this case, a malicious app could request
its own verifier code and successfully obtain authorization using the tcse

Obviously this does not negate the value of the proposal, but it's
something I'd expect readers to keep in mind.

In particular, it has very strong implications for whitelisted
authorizations, where no end user interaction is required. In such a case,
a malicious app could initiate a request at any time and the user would not
be in the loop to raise a question about its legitimacy.

On May 9, 2014 4:51 PM, "Brian Campbell" <bcampbell@pingidentity.com> wrote:
> I notice that code_verifier is defined as "high entropy cryptographic
random string of length less than 128 bytes"  [1], which brought a few
questions and comments to mind. So here goes:
> Talking about the length of a string in terms of bytes is always
potentially confusing. Maybe characters would be an easier unit for people
like me to wrap their little brains around?
> Why are we putting a length restriction on the code_verifier anyway? It
seems like it'd be more appropriate to restrict the length of the
code_challenge because that's the thing the AS will have to maintain
somehow (store in a DB or memory or encrypt into the code). Am I missing
something here?
> Let me also say that I hadn't looked at this document since its early
days in draft -00 or -01 last summer but I like the changes and how it's
been kept pretty simple for the common use-case while still allowing for
crypto agility/extension. Nice work!
> [1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth