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

[Nat Sakimura <[e-mail]>]

Hi Eduardo, 

I have accepted all the "Suggestions" in the forthcoming 
version. You can see my private editing copy at 

https://bitbucket.org/Nat/oauth-spop/commits/f0f8599

to see how it has been incorporated. 

Best, 

Nat

On Wed, 03 Sep 2014 01:57:31 -0600
Eduardo Gueiros <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth


-- 
Nat Sakimura ([e-mail])
Nomura Research Institute, Ltd. 

本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信
することを意図しております。意図された受取人以外の方によるこれらの情報の
開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メール
を受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受
信されたメールを削除していただきますようお願い致します。 PLEASE READ:
The information contained in this e-mail is confidential and intended
for the named recipient(s) only. If you are not an intended recipient
of this e-mail, you are hereby notified that any review, dissemination,
distribution or duplication of this message is strictly prohibited. If
you have received this message in error, please notify the sender
immediately and delete your copy from your system.