Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt

[Torsten Lodderstedt <[e-mail]>]

Am 10.05.2010 00:25, schrieb Eran Hammer-Lahav:
>
>> 3.2.1.  Response Format
>>
>> The authorization server MUST include the HTTP "Cache-Control"
>>      response header field with a value of "no-store" in any response
>>      containing tokens, secrets, or other sensitive information.
>>
>> Would'nt it make sense to require "no-cache", too?
>>      
> No idea.
>    

I checked back with the rfc2616. I apparently misinterpreted the 
semantics of the field and withdraw the question :-)

>> expires_in
>>
>> Why is there information passed back about the access tokens duration but
>> not about the refresh tokens duration?
>>      
> No one asked for that. Is there interest in specifying the authorization duration in addition to the token duration?
>    

Hmmm, is most people's assumption that refresh tokens never expire? Our 
refresh tokens will expire.

And if an application is interested to know the duration of the access 
token it will also consider the refresh tokens duration. Some people 
will probably ignore both data and wait until the access/refresh token 
gets rejected by the service/authorization server. So the error message 
"authorization_expired" of the "refresh" request is much more important.

>> 3.4.  Client Credentials
>>
>> The client credentials include a client identifier and
>>      an OPTIONAL symmetric shared secret.
>>
>> What is meant by "symmetric shared secret"? I'm familiar with the term
>> "symmetric" in the context of cryptographical algorithms only. I think "shared
>> secret" is sufficient.
>>      
> Shared secret can be symmetric (password) or asymmetric (key pair).
>    

Which secret is shared in the asymmetric case?

>    
>> 3.5.  User-Agent Flow
>>
>> These clients
>>      cannot keep client secrets confidential and the authentication of the
>>      client is based on the user-agent's same-origin policy.
>>
>> Does this still hold in the context of "HTTP Origin Headers"
>> (http://www.petefreitag.com/item/702.cfm)?
>>
>> BTW: Will Brian's security considerations document be updated to be in sync
>> with the draft?
>>      
> Brian's document was written for WRAP. We need to write a full security review for 2.0 that is structure similarly to OAuth 1.0.
>    
---I copied the folliwing from other messages in this thread---
<Dick Hardt>

>Besides changing some terminology, I would think Brian's doc would be
>  mainly reusable. Perhaps you could insert a version with changes you
>  understand, then people can suggest changes that need to be made.

<Eran Hammer-Lahav>
>Since the security section is all non-normative language, it is the least important part on my list. Brian's document is useful but is not something I can work with>quickly. If someone wants to take a stab at converting it into a section that can be cut-and-paste into the draft, I would be very happy to incorporate it.


Is reformatting this document really sufficient?

I would like to assess the specification's security level from the 
perspective of our usage scenarios. What I miss in the document is a 
threat model of OAuth along with relations between possible threats and 
respective countermeasures. So do I have to built this model on my own? 
Or will there be a joint effort?

>> 3.5.1.1.  End-user Grants Authorization
>>
>> I would suggest to use JSON encoding here, since the URI fragment is
>> handled by a client more or less like a response result.
>>
>> 3.6.1.1.  End-user Grants Authorization
>>
>> Why not call the "code" Parameter "verification_code"? It's called verification
>> code in the text.
>>      
> Longer for no reason.
>    

  for  the  sake  of  clarity?

>    
>> 3.6.2.  Client Requests Access Token
>>
>> client_secret
>>            REQUIRED if the client identifier has a matching secret.  The
>>            client secret as described in Section 3.4.
>>
>> 1) I'm having trouble to understand the meaning of  "if the client identifier
>> has a matching secret". Is the assumption underneath that authorization
>> servers require this secrets from all clients they have issued a secret to?
>> What about client w/o a secret? Are they also allowed to use this flow?
>> Or is there envisioned a dependency
>> between the client type, clients credentials and the flows a particular client is
>> authorized to use?
>>
>> I would have expected a clear policy which flows require authentication and
>> which not.
>>      

Did you miss this question?

>> 3.7.2.  Client Requests Access Token
>>
>> "authorization_declined"
>>
>> Why does the spec interpret a request as bad request if the user just has
>> declined the authorization? According to rfc2616 the semantics of
>> 400 is: "The request could not be understood by the server due to
>> malformed syntax".
>>
>> The calling client did not sent a malformed request, it cannot foresee or
>> influence this outcome. I would suggest to either use status 403 or to return
>> status code 200 for all syntactically correct and authorized request and to use
>> another return codes in the response body to detail the requests outcome.
>>      

Did you miss this question?

>> 4.  Username and Password Flow
>> 4.1.  Client Requests Access Token
>>
>> As statet in this section's introduction, this flow is intended to migrate
>> existing clients from BASIC/DIGEST to OAuth. I therefore would suggest to
>> use excactly these HTTP authentication schemes to transfer user credentials.
>> This would mean to remove the parameters "username"
>> and "password" and to use Authorization headers instead. At Deutsche
>> Telekom, we have to deal with that class of clients. Such clients have already
>> implemented their credential handling including header manipulation. The
>> proposed change would further simplify their migration.
>>      
> How would you send both client credentials and user credentials? Migration is only one example.
>    

I withdraw this proposal. As I have written in my response to "Open 
Issues: Group Survey": I would leave the end-user credential handling as 
is in favour of using Authorization headers for client authentication 
only. This will convey clarity.

>> 6.  Assertion Flow
>>
>> This flow is suitable when the client is acting autonomously or on behalf of
>>      the end-user (based on the content of the assertion used).
>>
>> Let's assume the assertion attests an end-user's identity. How shall the
>> authorization server determine the clients identity in this case? I would
>> suggest to add optional client_id/client_secret parameters (or an
>> Authorization header) for that case.
>>      
> That's the whole point - it doesn't need it because it uses a different trust framework where the client identity is part of.
>    

Could you please elaborate on the term trust framework? A SAML assertion 
contains at most one identity but we need two of them. Where should the 
second identity come from?

>> 7.  Refreshing an Access Token
>>
>> I would suggest to add an optional "scope" parameter to this request.
>> This could be used to downgrade the scope associated with a token.
>>      
> That would be the wrong way to do it given that people will expect to also be able to upgrade scope.
>    

What would be the right way?

>> 8.1.  The Authorization Request Header
>>
>> I consider the name "Token" of the authentication schema much to generic.
>> That was also the feedback of all colleagues I talked to about the upcoming
>> standard. Why not call it "OAuth2"?
>>      
> It is meant to be generic. I consider OAuth to be the part of the protocol dealing with getting a token. There will be many new ways to get a token in the future.
>    

That's interesting! I consider the authentication scheme the major 
contribution of OAuth since it allows for a standardized way of service 
interaction. So 3rd party software components can be integrated into a 
companies infrastructure (incl. AS) w/o customization. Moreover, as you 
pointed out, there will be many other ways to get tokens in the future.

>    
>> 8.2.2.  Form-Encoded Body Parameter
>>
>> I would suggest to drop this section/feature.
>>
>> General note: Would it make sense to add explicit format handling to the
>> OAuth API? If we envision authorization servers supporting more than one
>> token format (e.g. SAML, SWT, ...), the client should given the option to
>> request a certain format and responses returning access tokens should
>> indicate the format of this token. The OAuth authorization header could also
>> have an optional format attribute for the same purpose.
>>      
> You mean token format? OAuth defined the token as opaque so that would be counter-productive.
>    

I dont't mean OAuth shall define token formats. I just ask for a way to 
request tokens in a particular format and pass such meta data from AS to 
resource server via the client. Why is that counter-productive? 
Otherwise the resource server has to implement some token format discovery.

regards,
Torsten.
> EHL
>