Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2)

From: Mark Nottingham <[email-masked]>
Date: Thu, 8 Oct 2009 15:15:44 +1100

Digging up some feedback I sent privately a long while back WRT  
problem reporting (so apologies if the drafts have move on since)...

* Overall, I don't think that this is the right approach to solving
these sorts of problems (or writing a protocol generally); while there
is a place for error reporting, it's important to build more error
avoidance into the protocol so that reporting isn't necessary. Instead
of telling people what signature methods you accept after the fact,
advertise it in the challenge. Instead of telling them that they need
additional authentication in a parameter, use another challenge (or
the first one). This is more declarative, avoids round-trips, and
generally simplifies things.

* version_rejected - What's with this? If you're talking about minor
versions, changes should be backwards-compatible, so there's no need
to barf. If you're talking about major versions, you should use a
different scheme name, and let HTTP tell them that the auth scheme
isn't supported.

* parameter_absent - This is overkill; if your protocol is so complex
that you need to do this, it's a very bad sign, and only serves to
make the protocol *more* complex. Is there anything useful that a non-
human recipient can do with this?

* parameter_rejected - Unrecognised parameters should be ignored; see
Postel.

* token_revoked / token_rejected - What is the practical difference
between these, if any?

* user_refused - this seems very fuzzy.

* oauth_acceptable_timestamps - this creates a race condition. If you
really need to inform users of the window for timestamps (seems like a
security risk to me, and in any case they often won't be able to do
much about it, because any skew you see will be caused by network and
processing on both ends), use a delta (e.g., '5' = +- five seconds).

* Your parameter names are quite verbose (e.g.,
oauth_parameters_rejected); this, in combination with the fact that
there are so many, may cause the header to be too large, and in any
case is going to push some messages over packet boundaries. How about
trimming them (e.g., params_rej)?

Cheers,

On 22/09/2009, at 6:40 AM, Eran Hammer-Lahav wrote:

> http://tools.ietf.org/html/draft-ietf-oauth-authentication
> http://tools.ietf.org/html/draft-ietf-oauth-web-delegation
>
> I plan to publish new revisions of the above drafts to include:
>
> * Error codes and optional debug information
> * Cleanup of the authentication extensibility model
> * Change the version / protocol extensibility model
>
> In addition to general feedback about the drafts, I am looking for  
> specific feedback on the following items which I plan to address in  
> the next drafts:
>
> * Drop core support for the RSA-SHA1 method
> * Replace HMAC-SHA1 with HMAC-SHA256
> * Define the authentication parameters as method-specific (for  
> example, drop nonce and timestamp from PLAINTEXT)
> * The proposed Problem Reporting extension [1], its richness and  
> complexity
> * Making the HMAC signature method required for all server  
> implementations
> * Changing the delegation flow to require HTTP POST instead of  
> recommending it
> * Mandating server support for all three parameter transmission  
> methods
> * Adding a token revocation endpoint
> * Adding the ability for servers to declare their configuration  
> (methods, etc.) in the WWW-Authenticate header response
> * The value of the client credentials (Consumer Key) and feedback  
> from actual implementation experience
>
> In order for your feedback to be included or considered for the next  
> revisions it must be received by 10/2 on the [email-masked] list.
>
> EHL
>
> [1] http://wiki.oauth.net/ProblemReporting
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

--
Mark Nottingham     http://www.mnot.net/

---

From: John Panzer <[email-masked]>
Date: Thu, 8 Oct 2009 00:10:35 -0700

One minor meta-comment:
--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer

On Wed, Oct 7, 2009 at 9:15 PM, Mark Nottingham <[email-masked]> wrote:

> Digging up some feedback I sent privately a long while back WRT problem
> reporting (so apologies if the drafts have move on since)...
> ...

You're probably not advocating this, but: Postel's Law applied blindly to
security protocols can lead to disaster.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Oct 2009 14:18:51 +1100

So, Postel aside, rejecting any request with unrecognised parameters  
in it will rule out any backwards-compatible extensions to the  
protocol (practically; although the client can re-submit the request  
without the parameter, it disincents the introduction of backwards- 
compatible features).

Does the OAuth community really want to do this? And, what's the  
attack vector that is protected against here?

Cheers,

On 08/10/2009, at 6:10 PM, John Panzer wrote:

> You're probably not advocating this, but: Postel's Law applied  
> blindly to security protocols can lead to disaster.
>

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 14 Oct 2009 01:03:45 -0400

I tend to agree with Mark in that I don't see a security threat that 
could explore an act of ignoring a parameter.

Igor

Mark Nottingham wrote:
> without the parameter, it disincents the introduction of 
> backwards-compatible features).
>