Subject: Re: [apps-discuss] Appsdir review of draft-ietf-oauth-v2-23

From: Eran Hammer <[email-masked]>
Date: Wed, 7 Mar 2012 16:49:31 -0700

Thanks Henry.

> -----Original Message-----
> From: Henry S. Thompson [mailto:[email-masked]]
> Sent: Tuesday, February 07, 2012 9:31 AM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; Eran Hammer; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: Appsdir review of draft-ietf-oauth-v2-23
> 
> I have been selected as the Applications Area Directorate reviewer for this
> draft (for background on appsdir, please see
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
> 
> Please resolve these comments along with any other Last Call comments you
> may receive. Please wait for direction from your document shepherd or AD
> before posting a new version of the draft.
> 
> Document: draft-ietf-oauth-v2-23
> 
> Title: The OAuth 2.0 Authorization Protocol
> 
> Reviewer: Henry S. Thompson
> 
> Review Date: 2012-02-07
> 
> IETF Last Call Date: 2012-01-24
> 
> Summary: This draft is almost ready for publication as an Proposed
>          Standard but has a few issues that should be fixed
>          before publication
> 
> [Note - My expertise is in the areas of markup and architecture, with only the
> average geek's understanding of security and cryptographic technologies.
> Any comments below on security issues are therefore of the nature of
> general audience concerns, rather than technical worries.]
> 
> Major Issues:
> 
> 3.1.2.1  The failure to require TLS here is worrying.  At the very least I would
> expect a requirement that clients which do _not_ require TLS MUST provide
> significant user feedback calling attention to this
> -- by analogy, absence of a padlock does _not_ suffice. . .

Added:

              If TLS is not available, the authorization server SHOULD warn
              the end-user about the insecure endpoint prior to redirection.

> 3.1.2.5  In a somewhat parallel case, I would expect this section to at least
> explain why the SHOULD NOT is not a MUST NOT. Since in practice the
> distinction between trusted and untrusted 3rd-party scripting is difficult if not
> impossible to draw, as written the 2nd para is effectively overriden by the
> third.

New text replacing the last two paragraphs:

              The client SHOULD NOT include any third-party scripts (e.g. third-party analytics,
              social plug-ins, ad networks) in the redirection endpoint response. Instead, it
              SHOULD extract the credentials from the URI and redirect the user-agent again to
              another endpoint without exposing the credentials (in the URI or elsewhere). If
              third-party scripts are included, the client MUST NOT ensure that its own scripts
              (used to extract and remove the credentials from the URI) will execute first.

> 11  It seems at best old-fashioned that the designer of a new access token
> type, parameter, endpoint response type or extension error has no better
> tool available than Google to help him/her discover whether the name they
> have in mind is in use already.  The same is true under the proposed
> approach for any developer trying to determine what they can use or must
> support.  Is there some reason that mandated URI templates, after the
> fashion of
> 
>   http://www.iana.org/assignments/media-types/text/...
> 
> are not mandated for the registries, e.g.
> 
>   http://www.iana.org/assignments/access-token-types/bearer
> 
> ?  If there is a good reason, please use it to at least explicitly acknowledge
> and justify the basis for failing to provide a way for users and developers to
> use the "follow your nose" strategy [1].  If there is no good reason, please
> include the appropriate language to require something along the lines
> suggested above.  If you need a model, see [2].

Not sure what to do here to make this change. See other note.

> Minor Issues:
> 
> A short summary of the changes from OAuth 1.0/RFC5849 would have been
> helpful, and it might still be a good idea to add one. . .

Not possible. Two different protocols.

> 4.1  Would it be helpful to indicate that steps D&E may occur at any time after
> C, and may be repeated subsequently?

That's not always right. Some servers may choose to time limit the delay between C and D. Elsewhere in the document, D is stated as allowed only once.

> 11.1  It might be useful to have an 11.1.2, which repeats references to the
> bearer and mac access token type registration drafts?

Maybe. We'll see how all these progress before AUTH48. Can easily add those then.

EH

---

From: [email-masked] (Henry S. Thompson)
Date: Thu, 08 Mar 2012 15:11:32 +0000

Eran Hammer writes:

> HST wrote:

>> 3.1.2.1 The failure to require TLS here is worrying.  At the very
>> least I would expect a requirement that clients which do _not_
>> require TLS MUST provide significant user feedback calling
>> attention to this -- by analogy, absence of a padlock does _not_
>> suffice. . .
>
> Added:
>

Good, thanks.

>> 3.1.2.5 In a somewhat parallel case, I would expect this section to
>> at least explain why the SHOULD NOT is not a MUST NOT. Since in
>> practice the distinction between trusted and untrusted 3rd-party
>> scripting is difficult if not impossible to draw, as written the
>> 2nd para is effectively overriden by the third.
>
>      The client SHOULD NOT include any third-party scripts
>      (e.g. third-party analytics, social plug-ins, ad networks) in
>      the redirection endpoint response. Instead, it SHOULD extract
>      the credentials from the URI and redirect the user-agent again
>      to another endpoint without exposing the credentials (in the
>      URI or elsewhere). If third-party scripts are included, the
>      client MUST NOT ensure that its own scripts (used to extract
>      and remove the credentials from the URI) will execute first.

Good, thanks, but surely now "MUST NOT" --> "MUST" ?

> Not possible. Two different protocols.

OK, fair enough -- but even a two sentence statement to that effect,
in order to defeat naive expectations such as mine, that they _are_
related, would be helpful.

>> 4.1 Would it be helpful to indicate that steps D&E may occur at any
>> time after C, and may be repeated subsequently?
>
> That's not always right. Some servers may choose to time limit the
> delay between C and D. Elsewhere in the document, D is stated as
> allowed only once.

Hmm, OK, not obvious to the first-time reader, which is why I thought
a clarification would be helpful . . .

> Maybe. We'll see how all these progress before AUTH48. Can easily

Fair enough.

I'm satisfied, given the above changes.

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]