Subject: [OAUTH-WG] What are the primary criteria in issuing an authentication challenge?

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 27 Jan 2010 20:11:57 -0700

An authentication challenge (to make sure we are all on the same page) is something the server sends to the client when denying access to a protected resource. The challenge can be as simple as "use Basic", or complex as "use Digest with the following parameters". OAuth 1.0 doesn't really use a challenge because it was created for cases where the API calls are preconfigured and hardcoded into the client. The client should never receive an OAuth challenge the way the protocol was originally designed.

In my token authentication draft I tried to propose multiple mechanisms (not fully baked yet) for issuing a challenge and allowing the client to figure out what to do next. Before producing another draft, it is important to figure out what challenge model we want to use. Here are the general options I came up with:

1. Basic / OAuth 1.0 style - Simply say "use Token". The client is left on its own to figure out what to do next.

2. Basic / OAuth 1.0 + simple discovery - Say "use Token and if you need a new token go there". It is still not clear how this will help the client given that getting a token is likely it include many different options, and to fully address this we need to dig deep into discovery which was left out of scope.

3. Token attributes - the server informs the client of the kind of tokens accepted (based on their cryptographic properties or the resource-set/realm they are good for). This is just like #2 but with the ability for the server to support more than one token type per resource.

Question: Is the ability for a single token-protected resource to support more than one token type (say Plain+SSL *and* HMAC-256) part of our requirements? If not, there is no reason at all for the challenge to include anything other than #1 or #2 (probably defined as a future extension).

EHL

---

From: David Recordon <[email-masked]>
Date: Wed, 27 Jan 2010 20:36:31 -0800

I'm in the #1 camp from a simplicity standpoint.  Even if you're able to
discover an API endpoint (ala #2), you're still going to need to know more
than just how to authorize in order to make successful API requests.  This
isn't to say that we won't get there, but I think we're still a ways off.

--David

On Wed, Jan 27, 2010 at 7:11 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> An authentication challenge (to make sure we are all on the same page) is
> something the server sends to the client when denying access to a protected
> resource. The challenge can be as simple as "use Basic", or complex as "use
> Digest with the following parameters". OAuth 1.0 doesn't really use a
> challenge because it was created for cases where the API calls are
> preconfigured and hardcoded into the client. The client should never receive
> an OAuth challenge the way the protocol was originally designed.
>
> In my token authentication draft I tried to propose multiple mechanisms
> (not fully baked yet) for issuing a challenge and allowing the client to
> figure out what to do next. Before producing another draft, it is important
> to figure out what challenge model we want to use. Here are the general
> options I came up with:
>
> 2. Basic / OAuth 1.0 + simple discovery - Say "use Token and if you need a
> new token go there". It is still not clear how this will help the client
> given that getting a token is likely it include many different options, and
> to fully address this we need to dig deep into discovery which was left out
> of scope.
>
> 3. Token attributes - the server informs the client of the kind of tokens
> accepted (based on their cryptographic properties or the resource-set/realm
> they are good for). This is just like #2 but with the ability for the server
> to support more than one token type per resource.
>
> Question: Is the ability for a single token-protected resource to support
> more than one token type (say Plain+SSL *and* HMAC-256) part of our
> requirements? If not, there is no reason at all for the challenge to include
> anything other than #1 or #2 (probably defined as a future extension).
>
> EHL
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: "Paul C. Bryan" <[email-masked]>
Date: Wed, 27 Jan 2010 20:44:20 -0800

I'm in the #1 camp too. Is it wrong for me to think that discovering
what type(s) of token are acceptable and how to obtain them should be
the domain of XRD?

Paul

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 27 Jan 2010 23:55:11 -0500

I'm in the "1.5" camp -- "Use Token with HMAC-SHA256".  There's no  
point to specifying acceptable tokens, since from the perspective of  
the authentication protocol, the token is an opaque string.  But it  
would be a good idea to specify what the parameters for the  
authentication should be.  The critical parameter is of course the  
signature algorithm the server will accept (I'm OK with just allowing  
one), but you might also provide a valid range for timestamps.

--Richard

On Jan 27, 2010, at 10:11 PM, Eran Hammer-Lahav wrote:

> An authentication challenge (to make sure we are all on the same  
> page) is something the server sends to the client when denying  
> access to a protected resource. The challenge can be as simple as  
> "use Basic", or complex as "use Digest with the following  
> parameters". OAuth 1.0 doesn't really use a challenge because it was  
> created for cases where the API calls are preconfigured and  
> hardcoded into the client. The client should never receive an OAuth  
> challenge the way the protocol was originally designed.
>
> In my token authentication draft I tried to propose multiple  
> mechanisms (not fully baked yet) for issuing a challenge and  
> allowing the client to figure out what to do next. Before producing  
> another draft, it is important to figure out what challenge model we  
> want to use. Here are the general options I came up with:
>
> 1. Basic / OAuth 1.0 style - Simply say "use Token". The client is  
> left on its own to figure out what to do next.
>
> 2. Basic / OAuth 1.0 + simple discovery - Say "use Token and if you  
> need a new token go there". It is still not clear how this will help  
> the client given that getting a token is likely it include many  
> different options, and to fully address this we need to dig deep  
> into discovery which was left out of scope.
>
> 3. Token attributes - the server informs the client of the kind of  
> tokens accepted (based on their cryptographic properties or the  
> resource-set/realm they are good for). This is just like #2 but with  
> the ability for the server to support more than one token type per  
> resource.
>
> Question: Is the ability for a single token-protected resource to  
> support more than one token type (say Plain+SSL *and* HMAC-256) part  
> of our requirements? If not, there is no reason at all for the  
> challenge to include anything other than #1 or #2 (probably defined  
> as a future extension).
>
> EHL
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 27 Jan 2010 23:01:55 -0700

Not really. The algorithm is part of the token not the challenge. Either you have a token for this resource or not, and if you have one, it tells you which algorithm to use. In other words, when you get a token, it comes with the algorithms it supports (if more than one) and whatever secrets required executing it. When the client gets the challenge, it makes no difference what the challenge includes because the token attributes dictate the rest.

I am assuming there isn't a need for a server to issue a token with multiple algorithm and then letting individual resources narrow it down.

EHL

> -----Original Message-----
> From: Richard L. Barnes [mailto:[email-masked]]
> Sent: Wednesday, January 27, 2010 8:55 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] What are the primary criteria in issuing an
> authentication challenge?
> 
> I'm in the "1.5" camp -- "Use Token with HMAC-SHA256".  There's no point to
> specifying acceptable tokens, since from the perspective of the
> authentication protocol, the token is an opaque string.  But it would be a
> good idea to specify what the parameters for the authentication should be.
> The critical parameter is of course the signature algorithm the server will
> accept (I'm OK with just allowing one), but you might also provide a valid
> range for timestamps.
> 
> --Richard
> 
> 
> > page) is something the server sends to the client when denying access
> > to a protected resource. The challenge can be as simple as "use
> > Basic", or complex as "use Digest with the following parameters".
> > OAuth 1.0 doesn't really use a challenge because it was created for
> > cases where the API calls are preconfigured and hardcoded into the
> > client. The client should never receive an OAuth challenge the way the
> > protocol was originally designed.
> >
> > mechanisms (not fully baked yet) for issuing a challenge and allowing
> > the client to figure out what to do next. Before producing another
> > draft, it is important to figure out what challenge model we want to
> > use. Here are the general options I came up with:
> >
> > different options, and to fully address this we need to dig deep into
> > discovery which was left out of scope.
> >
> > challenge to include anything other than #1 or #2 (probably defined as
> > a future extension).
> >
> > EHL
> >

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 28 Jan 2010 04:28:27 -0500

> Question: Is the ability for a single token-protected resource to support more than one token type (say Plain+SSL *and* HMAC-256) part of our requirements? If not, there is no reason at all for the…

A good question!  I never thought about that before.  I tend to think 
that it is better to be forward-looking and support more than one token 
type.

Igor

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 28 Jan 2010 09:56:12 -0500

So you're assuming that somewhere in the process of token issuance,  
the client gets told what algorithm to use and remembers it.

When is this assumption true?  I don't see where it happens in the  
OAuth delegation procedure (there's no "use this algorithm" field in  
responses that issue tokens/secrets). And if Token auth is being used  
as a general authentication mechanism, the token secret might just be  
something like a password, which the user remembers, not the UA, so  
the UA would need to be informed somehow (by the user or the server)  
of what signing algorithm to apply.

--Richard

On Jan 28, 2010, at 1:01 AM, Eran Hammer-Lahav wrote:

> Not really. The algorithm is part of the token not the challenge.  
> Either you have a token for this resource or not, and if you have  
> one, it tells you which algorithm to use. In other words, when you  
> get a token, it comes with the algorithms it supports (if more than  
> one) and whatever secrets required executing it. When the client  
> gets the challenge, it makes no difference what the challenge  
> includes because the token attributes dictate the rest.
>
> I am assuming there isn't a need for a server to issue a token with  
> multiple algorithm and then letting individual resources narrow it  
> down.
>
> EHL
>
>> point to
>>> access
>>> allowing

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 28 Jan 2010 14:12:34 -0700

> Sent: Thursday, January 28, 2010 6:56 AM
 
> So you're assuming that somewhere in the process of token issuance, the
> client gets told what algorithm to use and remembers it.

Yep.

> When is this assumption true?  I don't see where it happens in the OAuth
> delegation procedure (there's no "use this algorithm" field in responses that
> issue tokens/secrets).

In 1.0 it's implied. The signature method is "delivered" via the API documentation. Since 1.0 includes a single HMAC method and a single RSA, and they each use very different secrets, the token you get is already bound to an algorithm (and you know it ahead of time).

As soon as we allow (and we have wide consensus that we will) more than one algorithm per family (HMAC, RSA, etc.), we need spell out which algorithm the token was created to work with. While the same secret can be used for both HMAC-SHA1 and HMAC-SHA256, this is not always true and it is better to explicitly bind the token secret (or other properties) to the cryptography used with it.

> And if Token auth is being used as a general
> authentication mechanism, the token secret might just be something like a
> password, which the user remembers, not the UA, so the UA would need to
> be informed somehow (by the user or the server) of what signing algorithm
> to apply.

We still don't know what this means. The previous discussion about this showed that using the token method to send human passwords is not going to improve much over Basic, other than requiring SSL. But either way, if we figure out how to use a human password to make an authenticated request, we will define a profile for it that will come with an implied token algorithm.

EHL

---

From: George Fletcher <[email-masked]>
Date: Thu, 28 Jan 2010 17:01:10 -0500

That definitely seems like a viable option.

Thanks,
George