Re: [OAUTH-WG] comments on draft-hammer-oauth-03

[Peter Saint-Andre <[e-mail]>]

On 11/18/09 4:03 PM, Eran Hammer-Lahav wrote:
> 
>> -----Original Message----- From: Peter Saint-Andre
>> [mailto:[e-mail]] Sent: Wednesday, November 18, 2009 1:33
>> PM
> 
>>>> 12. In Section 3.6, we say that "Text values are first encoded
>>>> as UTF- 8" but it's not fully clear to me which values this
>>>> applies to or exactly where in the protocol the encoding rules
>>>> are applied.
>>> I added an introduction to the section. This has always been a
>>> sore point and underspecified. I am happy to consider
>>> clarifications.
>> Now it's clear that these rules apply to the signature base string.
>> I think that it would be even clearer as follows:
>> 
>> This specification defines the following method for percent- 
>> encoding of parameter values that are used as input to construction
>>  of the signature base string:
>> 
>> (I say this because it's not 100% clear which strings are meant in
>> the current text -- i.e., does the method apply only to the values
>> in the name/value pairs?)
> 
> I'll take a look. The problem is we "accidently" applied the encoding
> method to the authorization header... This means this specific way of
> encoding leaked out of the signature base string scope. This makes it
> a bit hard to be so specific about its context. I can try to be more
> specific by saying it is for the SBS and header, but does not apply
> to parameter encoding in the query or body... Not sure how much that
> will help though.

That's not a disaster, I just thought it would be good to clarify the
context to forestall confusion. But I don't know if this is a source of
confusion at present.

>>>> 13. In Section 4, I think that a brief flow diagram would be 
>>>> helpful to illustrate the authorization process (e.g., this
>>>> would provide context for why the client obtains a set of
>>>> temporary credentials, which might not otherwise be obivous to
>>>> first-time readers of Section 4.1).
>>> I am going to dig Jeff's diagrams and see if I can make them work
>>> for this.
>> OK.
> 
> Still on my list pending more items.

IMHO this is nice but not necessary. Perhaps it's an item for the WG
items and not the informational spec.

>>>> 14. In Section 4.2 (or in a security consideration pointed to
>>>> from Section 4.2), it might be helpful to describe why
>>>> oauth_callback is important and the nature of the session
>>>> fixation attach that it helps to prevent.
>>> If someone wants to offer text, I am happy to consider. I don't
>>> write security text.
>> Perhaps we could borrow and adjust some text from your blog post at
>>  
>> http://hueniverse.com/2009/04/explaining-the-oauth-session-fixation-
>>  attack/ :)
> 
> Go for it... :-) It is one thing for me to write blog posts (with the
> review of Brian and Dirk), but another to write it for the spec.

I'll see what I can come up with.

>>>> 15. In Section 6.8, I think there is a non-sequitur. Just
>>>> because a client is a freely available desktop application does
>>>> not mean that an attacker will be able to recover the client
>>>> credentials. Perhaps one step in the chain of reasoning is not
>>>> spelled out here?
>>>> 
>>> If you have access to the client bits, you can reverse engineer
>>> it to get the secret. See DVD encryption key...
>> Again, I must be missing something. Just because I use Thunderbird
>> or Pidgin or some other free software doesn't mean you can hack
>> into my email or IM password. How is the case any different here?
> 
> No no. *You* can hack those applications and find their client
> credentials (not token credentials).

Yes, I figured that out now. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/