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

John Bradley <ve7jtb@ve7jtb.com> Mon, 10 November 2014 23:48 UTC

Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6F81AD094 for <oauth@ietfa.amsl.com>; Mon, 10 Nov 2014 15:48:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKJTYmuQPoPh for <oauth@ietfa.amsl.com>; Mon, 10 Nov 2014 15:48:54 -0800 (PST)
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9406B1AD0B7 for <oauth@ietf.org>; Mon, 10 Nov 2014 15:48:53 -0800 (PST)
Received: by mail-wg0-f45.google.com with SMTP id x12so10251776wgg.32 for <oauth@ietf.org>; Mon, 10 Nov 2014 15:48:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=dQVmCCDCPPsyi1fCOd4v9PMXBsIx1vIjluSFOjncFmI=; b=M4gQLIRPD0YQYg7EJ6sP1P0sbJw8oKywZF0r0uOs4/UcitOFemDifsXJ06blncUVdp 909BDql98aCLp2KMA434z3h8fwDqnkKXoJ1tldLYSzwE7tSPv/khKnBnrE6qONqBgrYC vJb0w6zisozj94TSEZASyq0+/r+znGT46pImfTNyxNX12Jjs5AUEOjVBCYKugd50pRUW klrt/5IM4sVIR7y7iUywiynyVRiI3HJE2d0zqMMsC3CtNUul1STiVyFtwtA+tUSDybBk hN/RegkMlVNBpdjguEu9uBbhFUpG689jgtrj68u2cq4qL3HsNhRzfXwpvZjdNJ4AAcPq 83tw==
X-Gm-Message-State: ALoCoQl0C6u70C1E6nuqiJGVCOLiCVwLsE7ROay2wk8J/o5duaFS4nG0wSO6mJdwnanuAM2vGFRm
X-Received: by 10.194.185.115 with SMTP id fb19mr47811013wjc.121.1415663331621; Mon, 10 Nov 2014 15:48:51 -0800 (PST)
Received: from t2001067c037001440d9d303c3785de96.hotel-wired.v6.meeting.ietf.org (t2001067c037001440d9d303c3785de96.hotel-wired.v6.meeting.ietf.org. [2001:67c:370:144:d9d:303c:3785:de96]) by mx.google.com with ESMTPSA id j8sm15247107wib.10.2014.11.10.15.48.49 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 15:48:51 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <5406C9EB.1020701@jive.com>
Date: Mon, 10 Nov 2014 13:48:45 -1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <DDA403C2-77EE-45A0-8BEB-077FF029F09A@ve7jtb.com>
References: <5406C9EB.1020701@jive.com>
To: Eduardo Gueiros <egueiros@jive.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/UwC04uPWq-w2NY4Kl-xGZgllLd4
Cc: oauth@ietf.org, draft-ietf-oauth-spop@tools.ietf.org
Subject: Re: [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: Mon, 10 Nov 2014 23:49:00 -0000

We did add a diagram but have not published that version yet due to the freeze on document updates prior to the IETF meeting this week.

in sec 4.1 we recommend using a 32 octet (256bit) random number that is base64url encoded to create a 42 octet string with the correct URLsafe character set.

With the S256 transform more bits don't add to the security.   

We limit the string size to 128 octets to limit the storage burden on the AS and to prevent the URI from becoming to long.  longer than 128 characters adds no real value for those transforms and is enough for a SHA512 hash if someone wants to define that transform at some point in the future.

If we allowed public key transforms 128 characters might be too small, but that would be an extension profile.

John B.

On Sep 2, 2014, at 9:57 PM, Eduardo Gueiros <egueiros@jive.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> 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
> interactions.
> 
> Abstract
> 
>> 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.
> 
> Introduction
> 
> 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
> 2.1
> Question
> Random String: What constitutes ‘big enough entropy’? Shouldn’t
> minimum length be specified (e.g. 32 characters)?
> 
> 3 Protocol
> 3.1
> Question
> 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.
> 
> 
> 3.3
> Question
> Goes with question on 2.1, why less than 128 bytes?
> 
> Suggestion
>> 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - https://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQEcBAEBCgAGBQJUBsnrAAoJEInLDRowktwYn6sH+wUGGCimGSRaSfy4LeN9ug9e
> VN5R/N4eWhEKl5iydMZskeMovYsH4PhEP19m56mWGhRn53CxMB5dlHkTw56JX4mS
> qnPu96Ot6HoCzzCVj8PtGyAZUwWFyd57Ff7uUuSQaVghhIfLXzggFfciiErJpV5H
> wwQo+eFp98fx6uGEeCr4Olr6PsJ8Ajn5SnaCA/dPr7YWAUrnpSb55NCB4twtp4y6
> 36EqjcuvafudTEuYJOoGqYJppfpcZ+Da6uKZNRTahkN1ivv1C+PdNRWkfHbB47mu
> IF4u3b6tDhiymPNFjCABZ6gB5ZbXmUbVrkhVKwJpf/87/fiaScGmZG+6rRZLP5s=
> =XQSw
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth