Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft

From: "Manger, James H" <[email-masked]>
Date: Wed, 3 Feb 2010 23:14:09 +1000

Hello OAuthers,

I have a couple of comments on the "Token Access Auth" draft.

Initial impression (as Eran asked for): Yuck.
Now I will try to be a bit more constructive.

This authentication draft breaks the existing model of HTTP authentication too much. It puts a bunch of very different mechanisms (bearer, shared secret, and public key crypto) into a single "Token" scheme. We should, instead, have 1 scheme per mechanism, which is how HTTP auth has been designed.
I agree with Dan Winship [email 2009-12-09] that a meta-scheme ("Token") with multiple sub-schemes will not work well with existing code architectures, which offer extensibility based on schemes, not based on any other parts of a WWW-Authenticate header.

It looks like 'realm' has been replaced by 'class'. This is working against the existing model for HTTP auth, without a compelling reason.

A major rational for separating OAuth into Delegation and Authentication documents was to recognize that they are logically independent. Authentication needs an id (eg a token or user-id) and, optionally, a key -- but has no dependence on delegation. Ideally, authentication specs would not mention (OAuth-style) delegation at all.
The authentication draft is too strongly bound to delegation by trying to package all authentication mechanisms that can be used with delegation under a single scheme. This cannot work.
There will be other schemes: at lower layers, signature in the URI, signing excluding the host name, using password-based key agreement, using multiple round-trips, non-http protocols etc.

I am not against developing a mechanism to sign HTTP requests with a shared secret. I think it is far less important for the OAuth working group than specifying the delegation flows, and signalling.

My suggestions:

1. Define 1 very simple bearer scheme -- with no mention of delegation. Don't include request signing in the same document.
  Eg  Authorization: ID a=<authorization-id>
  (use "WRAP" and "wrap_access_token" as labels if you must)

2. Optionally, work on a mechanism to sign an HTTP request with a shared secret without needing to exchange multiple messages with the server. Ensure the mechanism can include 2 ids (authentication id and authorization id), and a channel binding parameter.

Plus the main part of the WG work: on delegation flows; server-to-client signalling about how to do delegation (eg providing URI to redirect user to); stating which hosts and/or URIs a token (and optional secret) can be used at; working out how periodically refreshing credentials fits architecturally.

-- 
James Manger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Eran Hammer-Lahav
> Sent: Monday, 7 December 2009 7:28 PM
> To: OAuth WG ([email-masked])
> Subject: [OAUTH-WG] Token Access Authentication Scheme Draft
> 
> http://www.ietf.org/id/draft-hammer-http-token-auth-00.txt
> 
> This draft is my first attempt at defining a general purpose
> authentication scheme to fulfill the WG requirement to produce a scheme
> suitable for 2-legged authentication. It also supports the OAuth 3-
> legged use cases as discussed on the list. This draft is in very early
> stage and has been submitted early to help better facilitate the
> conversation.
> 
> It has been hard for us to discuss ideas without a concrete proposal. I
> hope this will help and motivate people to participate and provide
> feedback and new ideas. While there are many holes in the draft, it
> should be pretty easy to follow it.
> 
> Major changes from OAuth 1.0:
> 
> * New auth scheme with new parameter names
> * Signature base string replaced with normalized request string, and
> now does not require *any* encoding
> * Supports multiple token classes, authentication methods, and coverage
> scope
> 
> Main feedback requested:
> 
> * Initial impressions - this is particularly important to get. Does the
> draft make sense?
> * Functionality - does it include all the requested/required
> functionality?
> * Abstraction level - do the attributes provide the right level of
> configuration and choice?
> 
> Please refrain from editorial feedback at this point (grammar, typos,
> etc.), but do provide structural feedback.
> 
> I plan to push an updated version by Wed which will incorporate as much
> feedback as I can. I plan to ask for the WG to promote this draft to a
> WG item within 2 weeks.
> 
> Thanks,
> 
> EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 3 Feb 2010 09:26:45 -0700

Thanks James.

Your feedback is a bit late as the draft I am working on how drops the challenge details completely, leaving only the indication that the server supports the Token scheme and using a realm to help the client figure out which token to use (if they have more than one suitable for this resource).

The reason why it makes little sense to have different schemes for different types of tokens is that it is not the protected resource's job to say which algorithm should be used, but the server when issuing the token for that resource. The draft did a poor job at separating the role of the server issuing the tokens from the role of the server providing access to resources.

As a side note, 'class' was my placeholder parameter for replacing 'realm' (or at least suggesting that we take a look at that). Given the strong feeling here that there isn't really a current use case for servers issuing multiple tokens (of different properties) for a single realm and then allowing individual resources to reduce it to a smaller number of token types, there is no reason to go beyond 'realm'.

EHL

> Of Manger, James H
> Sent: Wednesday, February 03, 2010 5:14 AM
> Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft
> 
> Hello OAuthers,
> 
> This authentication draft breaks the existing model of HTTP authentication
> too much. It puts a bunch of very different mechanisms (bearer, shared
> secret, and public key crypto) into a single "Token" scheme. We should,
> instead, have 1 scheme per mechanism, which is how HTTP auth has been
> designed.
> I agree with Dan Winship [email 2009-12-09] that a meta-scheme ("Token")
> with multiple sub-schemes will not work well with existing code
> architectures, which offer extensibility based on schemes, not based on any
> other parts of a WWW-Authenticate header.
> 
> 
> It looks like 'realm' has been replaced by 'class'. This is working against the
> existing model for HTTP auth, without a compelling reason.
> 
> 
> A major rational for separating OAuth into Delegation and Authentication
> documents was to recognize that they are logically independent.
> Authentication needs an id (eg a token or user-id) and, optionally, a key --
> but has no dependence on delegation. Ideally, authentication specs would
> not mention (OAuth-style) delegation at all.
> The authentication draft is too strongly bound to delegation by trying to
> package all authentication mechanisms that can be used with delegation
> under a single scheme. This cannot work.
> There will be other schemes: at lower layers, signature in the URI, signing
> excluding the host name, using password-based key agreement, using
> multiple round-trips, non-http protocols etc.
> 
> 
> I am not against developing a mechanism to sign HTTP requests with a shared
> secret. I think it is far less important for the OAuth working group than
> specifying the delegation flows, and signalling.
> 
> 
> My suggestions:
> 
> 1. Define 1 very simple bearer scheme -- with no mention of delegation.
> Don't include request signing in the same document.
> 2. Optionally, work on a mechanism to sign an HTTP request with a shared
> secret without needing to exchange multiple messages with the server.
> Ensure the mechanism can include 2 ids (authentication id and authorization
> id), and a channel binding parameter.
> 
> Plus the main part of the WG work: on delegation flows; server-to-client
> signalling about how to do delegation (eg providing URI to redirect user to);
> stating which hosts and/or URIs a token (and optional secret) can be used at;
> working out how periodically refreshing credentials fits architecturally.
> 
> 
> --
> James Manger
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 4 Feb 2010 09:23:08 +1000

> The reason why it makes little sense to have different schemes for
> different types of tokens is that it is not the protected resource's
> job to say which algorithm should be used, but the server when issuing
> the token for that resource. The draft did a poor job at separating the
> role of the server issuing the tokens from the role of the server
> providing access to resources.

It is not the role of a spec for an HTTP authentication mechanism to make assumptions about how credentials are issued, or assumptions about what additional authentication mechanisms might be supported by any particular server. I hope a HTTP request-signing spec does not need to assume that a separate security server is involved to do all possible mechanism negotiation.

I am very happy for a security server to say:
  eg "use this token+secret with HMAC-SHA256 at http://api.example.org/ for 10 minutes"
A security server may want to be a little less specific:
  eg "use this token+secret with any MAC algorithm at http://*.example.com/"
Or
  eg "use this token+secret with the OAuth MAC algs or draft-oiwa-http-mutualauth at xyz".

A statement from a security server binding a token+secret to
  "1 or more 'mechanisms' of the 'Token' scheme"
is no easier than a statement binding then to
  "1 or more 'schemes'",
Binding to 'mechanisms' of the 'Token' scheme is significantly worse as it exclude a whole swag of current and future authentication mechanisms that are not written with OAuth specifically in mind.

--
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 3 Feb 2010 16:32:57 -0700

> From: Manger, James H [mailto:[email-masked]]
> Sent: Wednesday, February 03, 2010 3:23 PM
> To: Eran Hammer-Lahav; OAuth WG ([email-masked])
> Subject: RE: Token Access Authentication Scheme Draft
> 
> > the token for that resource. The draft did a poor job at separating
> > the role of the server issuing the tokens from the role of the server
> It is not the role of a spec for an HTTP authentication mechanism to make
> assumptions about how credentials are issued, or assumptions about what
> additional authentication mechanisms might be supported by any particular
> server.

It doesn't.

>   eg "use this token+secret with the OAuth MAC algs or draft-oiwa-http-

This is exactly what the current draft proposes, as long as these statements are "said" by the server when issuing the credentials, not when sending a 401 response.

All the spec is doing in that regard is giving these statements a common language to enable interop for a few methods.
 
EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 4 Feb 2010 00:42:42 -0700

Thanks Dan.

> From: Dan Winship [mailto:[email-masked]]
> Sent: Tuesday, December 08, 2009 11:00 AM

> If Token/OAuth is not intended for use with Proxy-Authenticate/Proxy-
> Authorization, then you should say that explicitly near the beginning, and if
> not, then everywhere you say "WWW-Authenticate" or "Authorization", you
> need to allow for the proxy versions as well. (Maybe just by saying
> "whenever I say WWW-Authenticate, I mean 'either WWW-Authenticate or
> Proxy-Authenticate'.")

I'll get to this if this draft ever makes it to the other side.

> I know you said you don't care about typos, but "OWF" should be "OWS".
> 
> "rsassa-pkcs1-v1.5-sha-256" is way too long a name. :)

Trying to be descriptive. The current RSA-SHA1 means nothing without reading the spec (it might as well be 'R1').
 
> The grammar for method-list says
> 
>     method-list     = "method" "=" <"> 1#method-name <">
> 
> where "1#method-name" in RFC2616 ABNF means a comma-delimited list of
> method-name. But the text (4.2) and the example quoted above use a
> space-delimited list. (Likewise with coverage-list.)

Right. I wanted it to be space-delimited.
 
> The first paragraph of section 5 seems to say that clients MUST include a
> Authorization header when requesting a protected resource even if they
> don't know that it's protected. :)

Changed to 'when making an authenticated request'.

> In theory, the information in the Authentication-Error response could just be
> included in WWW-Authenticate...

I am actually going to try and use Authentication-Info (expending its use beyond Digest and making it applicable for errors, not just success). Keeping this in a separate header makes it easier I think to parse the challenge. No strong feelings here.

> If error-message is supposed to be localized then you should allow for the
> RFC 2183 grammar (or eventually, the grammar from the RFC that draft-
> reschke-rfc2183-in-http becomes).

OK.

> The "normalized request string" says it includes both the hostname and the
> request URI, which would be redundant. Maybe when you say "request
> resource URI" you mean just the Request-URI production from the Request-
> Line (ie, the path+query), not the actual complete request URI?

Yeah, that's what I mean.

> You should clarify that. Although if the user is behind a proxy then the
> Request-URI will be a complete URI rather than just the path+query. So you
> might want to say something like "the path and query components of the
> request URI, as they appear in the Request-Line"?

                The request Request-URI exactly as it appears on HTTP Request-Line as defined by
                RFC2616> section 5.1.2.

> There have been interoperability problems with Digest auth digest
> computation because people weren't sure if the quotes around attribute
> values were considered part of the value or not when computing the hash.
> You should be explicit.

We didn't get this one in OAuth 1.0 (plenty of other issues)... seems like an odd thing to fail on. I'll note it.

> "Any authentication attribute, with the exception of the "auth", which is
> assigned a value (including default values), are added to the normalized
> request string as follows" is hard to understand. I think what you mean is
> "Any attribute which is present in the Authorization header, with the
> exception of "auth", is added to the normalized request string as follows".

Ok.

> Hm... although 7.1 seems to suggest something else.
> I'm not at all sure what attributes are supposed to be included in the
> normalized request string now.

Fixed.

> Would probably be good to have an example of computing the string.

If this makes it to the other side, I'll add plenty of examples in the spirit of draft-hammer-oauth.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 4 Feb 2010 00:50:12 -0700

First, congrats on the new member of the Eaton family.

> From: Brian Eaton [mailto:[email-masked]]
> Sent: Tuesday, December 08, 2009 10:43 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG ([email-masked])
> On Mon, Dec 7, 2009 at 11:52 PM, Eran Hammer-Lahav
> <[email-masked]> wrote:
> > Can you list the use cases it doesn't meet? This is largely a cosmetic
> > rewrite of 1.0 with the exception of directly supporting form-encoded
> > parameters which is still being discussed. Your reference is to a post about
> mostly non-HTTP use cases.
> 
> There are basically two use cases for the crypto in OAuth 1.0, and one major
> problem.
> 
> Major problem: people can't figure out the signature base string.
>     The new authentication spec does nothing to fix this, which is a shame.  It is
> solvable.

Can you offer alternatives other than including a base64 copy of what is being signed.

> Use case #1: security for people who won't use https.
>     We seem to have concluded that this isn't achievable. [1]

HTTPS will be a required part of the protocol. The question is, are we going to accommodate the case where HTTPS is not desirable for every protected resource request? There seems to be consensus that yes.

> Use case #2: security for people who need to send messages through
> untrusted third-parties.
>     The new authentication spec makes this much, much harder.
>
> Here are a few examples of places where people are using OAuth to send
> messages through untrusted third-parties.  Every single one of these use
> cases is broken by the token-auth spec [2].  If we can't solve these problems,
> there is very little point in message authentication at all.
> 
> For example:
> - signed URLs embedded in the browser [3]
> - opensocial identity parameters [4]
> - google-specific identity parameters [5]
> - intermediate xmpp servers [6]
> - intermediate sip servers [6]

What about the draft breaks these? Is it the need to access the raw HTTP request URI? That is the only difference between the token scheme and the current OAuth signature base string. This wasn't a new idea - I have asked about this more than once and the consensus was that it is not a problem. If it is, it certainly makes a difference and the side effect was not intentional.

EHL

> We should be trying to make those use cases *easier*, not make them
> impossible.  If we push a new OAuth spec that drops these use cases, we've
> done more harm than good.
> 
> Cheers,
> Brian
> 
> [1] http://www.ietf.org/mail-archive/web/oauth/current/msg00762.html
> [2] http://www.ietf.org/id/draft-hammer-http-token-auth-00.txt
> [3] http://www.ietf.org/mail-archive/web/oauth/current/msg00689.html
> [4] http://www.opensocial.org/Technical-Resources/opensocial-spec-
> v09/Gadgets-API-Specification.html#gadgets.io.makeRequest
> [5]
> http://code.google.com/apis/accounts/docs/OAuth.html#GoogleAppsOAut
> h
> [6] http://www.ietf.org/mail-archive/web/oauth/current/msg00513.html

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 4 Feb 2010 01:02:32 -0700

Thanks John.

> From: John Panzer [mailto:[email-masked]]
> Sent: Tuesday, December 08, 2009 11:29 AM

> Suggestion: It would be better to start with simple examples (bearer token)
> which avoids the need to wade through concepts like timestamp
> synchronization and authentication coverage in order to understand the
> simplest possible flow?  (E.g., the example in 1.2.)

I am not worried about examples at this point. There will be plenty more if this draft is adopted.

> Suggestion: Make it clear up front that protected resources are allowed and
> encouraged to put a WWW-Authenticate: header on all requests (even ones
> that return 200 for read-only access) to indicate what authentication is
> allowed in general.  (The equivalent of the "login" link on web pages that
> present a read-only view.)

Is this consistent with common practice?

> In general, I think that much of the text could be made simpler by separating
> out the coverage="none" case from the other cases.  At the moment the
> only method under discussion with coverage="none" is bearer token.  I think
> that's all there ever will be.  If that's correct, perhaps separating out things
> that way would lead to a simpler reading experience (for the bearer token-
> users for sure, and possibly for everybody else as they don't have to worry
> about the special case of coverage="none" over and over again.)

Agreed. I still need to rework the 'none' methods.
 
> Section 5: "A client making a request for a protected resource either directly,
>    or in retrying a request after receiving a 401 status code
>    (Unauthorized) with a token challenge, MUST include at least one
>    "Authorization" header field including token scheme credentials."
> - This could be read as forbidding clients from querying protected resources
> before figuring out what Authorization: header to use (as they sometimes
> need to make an initial request to discover that the resource is
> protected).  Possibly just rewording to "credentialled request"?  What is the
> right terminology here?

Authenticated request.

> Suggestion:  Calling the token method "none" is odd and jarring.  It makes me
> think about the classic routine "Who's on first?".  How about "bearer"?  As in,
> the method for request validation is to simply check that it bears the token.

Plain, bearer, unsigned, blue, whatever. Don't care. Others ok with 'bearer'?

> "relying solely on the
> value of the token identifier to authenticate the client"
> 
> Surely we are authenticating the request in all these
> methods?  (Authenticating the client may be a side effect, but it is neither
> necessary nor sufficient.)

Fixed.

> Suggestion:  Add a note (SHOULD) about using SSL / TLS when discussing the
> bearer token option, either within this section or in the security
> considerations section (couldn't find one after some searching).  It's implied
> by the discussion in section 8.1 but it's difficult to parse out.

I'm hoping to make this a MUST.

> "The "coverage"
> attribute MUST be set to "none" but MAY be omitted from the request."
> 
> This reads oddly -- I would assume that I can set it to anything if it's omitted
> :).  Suggestion:  MUST be either set to "none", or omitted from the request.

Well, the value goes into the normalized string...

> "Nevertheless, these attributes MUST be included in the normalized request
> string together with any other authentication attributes."
> 
> After quick read, I have no idea what this sentence means operationally.  Can
> you clarify?

That when you create the normalized string, they are included even if they are not sent on the wire. I tried to keep the normalized string consistent regardless of method used. Does this sound like a good/bad idea?

EHL

---

From: John Panzer <[email-masked]>
Date: Thu, 4 Feb 2010 23:41:38 -0800

> Is this consistent with common practice?

We successfully did it for all feeds on AOL Journals for several years, with
no bug reports.  I don't know if anyone has done a recent survey.  It's
certainly allowed by the protocol, and it's the simplest way to flag what
kind of auth is available IMHO.

> That when you create the normalized string, they are included even if they
> are not sent on the wire. I tried to keep the normalized string consistent
> regardless of method used. Does this sound like a good/bad idea?
>
>
That makes sense, but perhaps it would be good to make it more explicit: The
default values are explicitly included in the normalized string for purposes
of generating the signature, even if not sent on the wire.

(Are you sure it wouldn't be better to just eliminate default values
entirely?)