[OAUTH-WG] Review draft-ietf-oauth-spop-00

Eduardo Gueiros <egueiros@jive.com> Wed, 03 September 2014 07:58 UTC

Return-Path: <egueiros@jive.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 302C41A007E for <oauth@ietfa.amsl.com>; Wed, 3 Sep 2014 00:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Va83R3dKQVB0 for <oauth@ietfa.amsl.com>; Wed, 3 Sep 2014 00:58:00 -0700 (PDT)
Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87A791A0073 for <oauth@ietf.org>; Wed, 3 Sep 2014 00:57:39 -0700 (PDT)
Received: by mail-pa0-f43.google.com with SMTP id et14so16914734pad.2 for <oauth@ietf.org>; Wed, 03 Sep 2014 00:57:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=QBVG8hrb9lOs6EAH7iCQ7cRZKerbrx6GDBYR12RuvIo=; b=QcnCBBOljawb29RrxZpCPYFIbKPgm4Lb6QejW2K75bungXNHZ97RVhA32iSrMj/Y5Q WvfjCLteCPrVFK5+TL+Q8zfeHpZ2T09QKU2TV4U/8AoJwyiHr+Is3odd9HkeJWsLVdg0 hyHne3joo2dlkmugU+kh1tW6SkqmvM7cPjV5v/SM2zIJwYAw47Y8RiFoLO+HGibJ3ffy aqP/IBAlpePkkw/rYlmhYQ3vCIoTJKNDJyDryX0Zamn3wHsJVYdzjGMZ+S39rR7sLjRo VFOMy5cDI3rf0uj9tgk4aGlZrghl0slDbM8gSm+XwrNlOTrBo9tZyXQptcCaFChru3Zj zSVQ==
X-Gm-Message-State: ALoCoQlaYT+8m84f4RCnm/AN5Im5lG5ofSoXAvmyXEVhivDp+/9oNljYGKnCwVp809bzSs3/o+3G
X-Received: by with SMTP id ik1mr3148236pac.154.1409731055974; Wed, 03 Sep 2014 00:57:35 -0700 (PDT)
Received: from [] (c-71-195-233-26.hsd1.ut.comcast.net. []) by mx.google.com with ESMTPSA id pm1sm8310382pdb.58.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Sep 2014 00:57:34 -0700 (PDT)
Message-ID: <5406C9EB.1020701@jive.com>
Date: Wed, 03 Sep 2014 01:57:31 -0600
From: Eduardo Gueiros <egueiros@jive.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: oauth@ietf.org, draft-ietf-oauth-spop@tools.ietf.org
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/gSS3WJGWp3BwrUO-MkwWiHUBOCw
Subject: [OAUTH-WG] Review draft-ietf-oauth-spop-00
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, 03 Sep 2014 07:58:02 -0000

Hash: SHA512

Review of draft-ietf-oauth-spop-00

Gentleman, here are some notes on the OAuth SPOP Draft.

Review Summary

A few grammar errors, no major flaws, some suggestions that could
possibly make some passages clearer. Some questions as well.
Also, providing a flow diagram would help clarify some of the


> The OAuth 2.0 public client utilizing authorization code grant is 
> susceptible to the code interception attack.

Suggestion for clearer reading:
OAuth 2.0 public clients utilizing Authorization Code Grant (RFC 6749
- - 4.1) are susceptible to an interception attack.


Suggestion for clearer reading:
> Public clients in OAuth 2.0 [RFC6749] is susceptible to the "code" 
> interception attack.  The "code" interception attack is an attack 
> that a malicious client intercepts the "code" returned from the 
> authorization endpoint and uses it to obtain the access token.

Public clients utilizing OAuth 2.0 are susceptible to authorization
code interception attack. A malicious client intercepts the
authorization code returned from the authorization endpoint and uses
it to obtain the access token.

Suggestion for clearer reading:
> This is especially true on some smartphone platform in which the
"code" is
> returned to a redirect URI with a custom scheme as there can be 
> multiple apps that can register the same scheme.

This is especially true on smartphones applications where the
authorization code can be returned
through custom URL Schemes where the same scheme can be registered by
multiple applications.

Insert article before ‘dynamic’
> To mitigate this attack, this extension utilizes dynamically
> created cryptographically random key called 'code verifier'.

To mitigate this attack, this extension utilizes a dynamically created
cryptographically random key called 'code verifier'.

Missing commas for context
> The code verifier is created for every authorization request and
> its transformed value called code challenge is sent to the
> authorization server to obtain the authorization code.

The code verifier is created for every authorization request and its
transformed value, called code challenge, is sent to the authorization
server to obtain the authorization code.

2 Terminology
Random String: What constitutes ‘big enough entropy’? Shouldn’t
minimum length be specified (e.g. 32 characters)?

3 Protocol
This paragraph states that the client must, through some mechanism,
verify if the server supports this specification. Shouldn’t this
mechanism be part of OAuth and therefore have an specification
document on how to implement and perform the aforementioned verification?

Suggestion: Change MUST to SHOULD
> The client that wishes to use this specification MUST stop
> proceeding if the server does not support this extension.

I think a client can use this mechanism to implement a more secure
transaction, but by verifying it, the client can be configured to
continue performing the regular authorization grant if it chooses so.
Hence, SHOULD instead of MUST.

Goes with question on 2.1, why less than 128 bytes?

> string of length less than 128 bytes
string of length no less than 128 bytes

Eduardo Gueiros
Software Developer | Jive.com
Jive Communications, Inc | egueiros at jive.com
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/