Subject: [OAUTH-WG] Including token class in authenticated requests

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 6 Dec 2009 00:29:58 -0700

In my proposed approach, the server informs the client which token classes it supports at a given endpoint. The client knows the class of the token it received using the information provided by the server when issuing the token. The class of the token identified the cryptographic properties of the token (e.g. hmac-sha-1, hmac-sha-256, rsassa-pkcs1-v1.5-sha-256, bearer-opaque).

The server includes in the challenge the list of supported token classes:

	WWW-Authenticate: Token realm="generic", classes="hmac-sha-1 hmac-sha-256"

The question is, is it necessary for the client to inform the server back which token class it is using? Whether the server issued the token, or supports token classes issued by another entity (the client, third party, etc.), it is should be pretty easy for the server to know the properties of the token, simply by looking up the token identifier.

With the proposed 4 classes, the token is an opaque string which will require the server to either look it up in a database or decrypt it for self-contained information. Either way, in the current model knowing the token class is easy to do without having the client provide it. Future extensions defining new token classes (and I expect a few proposals before we are done with this work) can easily accommodate the need to identify the token class from the token identifier.

While it is trivial for the client to include this information, and it must have it either way since it picks the appropriate token based on the classes supported by the server, it is still incorrect to require the client to send wasteful information. On the other hand, this might be one of those optimizations that are just not worth the hassle, and the client can waste 20-40 bytes in each request sending the additional info.

Comments?

EHL

---

From: "Paul C. Bryan" <[email-masked]>
Date: Sat, 05 Dec 2009 23:41:58 -0800

On Sun, 2009-12-06 at 00:29 -0700, Eran Hammer-Lahav wrote:

> In my proposed approach, the server informs the client which token
> classes it supports at a given endpoint. The client knows the class of
> the token it received using the information provided by the server
> when issuing the token. The class of the token identified the
> cryptographic properties of the token (e.g. hmac-sha-1, hmac-sha-256,
> rsassa-pkcs1-v1.5-sha-256, bearer-opaque).
> 

Probably dumb bikeshedding question: why hmac-sha-1 and not hmac-sha1?

> The question is, is it necessary for the client to inform the server
> back which token class it is using? Whether the server issued the
> token, or supports token classes issued by another entity (the client,
> third party, etc.), it is should be pretty easy for the server to know
> the properties of the token, simply by looking up the token
> identifier.

While not technically necessary, I think it may be useful.

If the token is an opaque string (and should the server support multiple
opaque token formats), it's probably better to be explicit how the token
should be dealt with rather than leaving the server to its own devices
to trying to find a matching type.

Alternatively, as a workaround the opaque token itself could contain
some kind of identifier to identify its type, allowing the server to
quickly determine how to handle it.

> With the proposed 4 classes, the token is an opaque string which will
> require the server to either look it up in a database or decrypt it
> for self-contained information. Either way, in the current model
> knowing the token class is easy to do without having the client
> provide it. Future extensions defining new token classes (and I expect
> a few proposals before we are done with this work) can easily
> accommodate the need to identify the token class from the token
> identifier.
> 
> While it is trivial for the client to include this information, and it
> must have it either way since it picks the appropriate token based on
> the classes supported by the server, it is still incorrect to require
> the client to send wasteful information. On the other hand, this might
> be one of those optimizations that are just not worth the hassle, and
> the client can waste 20-40 bytes in each request sending the
> additional info.

In many deployments, it may be redundant, but I can see scenarios where
ambiguity will incur cost on the server, making someone wish to have it
explicitly identified when the token is provided.

My 2¢.

Paul

> 
> Comments?
> 
> EHL
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 6 Dec 2009 01:00:21 -0700

> -----Original Message-----
> From: Paul C. Bryan [mailto:[email-masked]]
> Sent: Saturday, December 05, 2009 11:42 PM

> Probably dumb bikeshedding question: why hmac-sha-1 and not hmac-sha1?

It’s the proper hash function name. You'll notice that the new class names are more descriptive and reflect what they are, as opposed to making names up (e.g. RSA-SHA1).
 
> Alternatively, as a workaround the opaque token itself could contain some
> kind of identifier to identify its type, allowing the server to quickly determine
> how to handle it.

That's my point. But if every server is going to define its own way of encoding this value, it means we can show a reason why it should be provided in a standard way. And that's my question...

EHL

---

From: Hubert Le Van Gong <[email-masked]>
Date: Sun, 6 Dec 2009 10:04:08 +0100

I don't think we can rely on every token format (present and future) to include
the same standardized way of describing its kind.
The client really ought to clearly indicate the kind of token it's
using in the request,
this is a common practice (e.g. WS-Trust for instance with the TokenType
attribute). As Paul indicated it can help the server handle the request.

Hubert

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 6 Dec 2009 11:13:57 +0000

On 6 Dec 2009, at 07:29, Eran Hammer-Lahav <[email-masked]> wrote:

> The class of the token identified the cryptographic properties of  
> the token (e.g. hmac-sha-1, hmac-sha-256, rsassa-pkcs1-v1.5-sha-256,  
> bearer-opaque).
That's just confusing. The examples are mac/signature schemes. If you  
want token classes something else is needed. What is "token class"  
supposed to mean?
S.

> token, or supports token classes issued by another entity (the  
> client, third party, etc.), it is should be pretty easy for the  
> server to know the properties of the token, simply by looking up the  
> token identifier.
>
> With the proposed 4 classes, the token is an opaque string which  
> will require the server to either look it up in a database or  
> decrypt it for self-contained information. Either way, in the  
> current model knowing the token class is easy to do without having  
> the client provide it. Future extensions defining new token classes  
> (and I expect a few proposals before we are done with this work) can  
> easily accommodate the need to identify the token class from the  
> token identifier.
>
> While it is trivial for the client to include this information, and  
> it must have it either way since it picks the appropriate token  
> based on the classes supported by the server, it is still incorrect  
> to require the client to send wasteful information. On the other  
> hand, this might be one of those optimizations that are just not  
> worth the hassle, and the client can waste 20-40 bytes in each  
> request sending the additional info.
>
> Comments?
>
> EHL
>

---

From: Hubert Le Van Gong <[email-masked]>
Date: Sun, 6 Dec 2009 12:32:08 +0100

Yeah I kind of agree the name might be misleading. Separating the 2
properties (token type and crypto) would be preferable.
Talking of token classes/types then we probably should reuse names
that already exist like: username token, binary token (similar I think to
the opaque one mentioned so far) and XML token.

Hubert

On Sun, Dec 6, 2009 at 12:13 PM, Stephen Farrell
<[email-masked]> wrote:
>> The class of the token identified the cryptographic properties of the
>> token (e.g. hmac-sha-1, hmac-sha-256, rsassa-pkcs1-v1.5-sha-256,
>> bearer-opaque).
>
> That's just confusing. The examples are mac/signature schemes. If you want
> token classes something else is needed. What is "token class" supposed to
> mean?
> S.
>
>>
>> The question is, is it necessary for the client to inform the server back
>> which token class it is using? Whether the server issued the token, or
>> supports token classes issued by another entity (the client, third party,
>> etc.), it is should be pretty easy for the server to know the properties of
>> the token, simply by looking up the token identifier.
>>
>> require the server to either look it up in a database or decrypt it for
>> self-contained information. Either way, in the current model knowing the
>> token class is easy to do without having the client provide it. Future
>> extensions defining new token classes (and I expect a few proposals before
>> we are done with this work) can easily accommodate the need to identify the
>> token class from the token identifier.
>>
>> must have it either way since it picks the appropriate token based on the
>> classes supported by the server, it is still incorrect to require the client
>> to send wasteful information. On the other hand, this might be one of those
>> optimizations that are just not worth the hassle, and the client can waste
>> 20-40 bytes in each request sending the additional info.
>>
>> Comments?
>>
>> EHL
>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 6 Dec 2009 11:35:00 -0700

Token credentials include:

* Identifier (what is usually considered the 'token')
* Identifier structure (opaque string, encoded value, XML/JSON syntax)
* Cryptographic properties/method (the black box applied to the normalized request to produce some kind of verifiable value)
* Shared-secret (optional, which can be embedded in the identifier or provided separately)

Tokens credentials also have:

* Realm - the protected resource segment they can be used to access
* Source/purpose - the process through which they have been obtained (directly/username, delegation)

I used the term class to identify the combination of these token properties. I agree that the proposed class names are confusing as they focus on only the cryptographic properties. But that can be solved with better names rather than a better term.

If all tokens were server-issued, the server would simply provide a server-specific token name and provide the cryptographic method to be used with it. For example, when the server issues a token, it will say:

name="supertoken", method="hmac-sha-1", secret="3hj2jh32", token="hkj3h3uhd"

Then when in the challenge it will ask for any "supertoken" using the "hmac-sha-1" method.

Why do we need a name? We need something to tell the client which token to use, and it should not be limited to just the cryptographic method used. This is the existing problem in Basic and Digest and why we need to define a new scheme which greatly overlaps them. They do not support any other classes of tokens other than username (yes, they can be used with other classes but only in a fully controlled client-server environment, not the real world).

The problem with a server-picked name, is that it only works with server-issued tokens. It is very likely that in the (near) future someone will want to define a self-issued token using PKI or other means. That requires the server to be able to express what it supports with something other than a server-picked name.

We can break all the properties into separate attributes. The problem with that is it requires the ability to declare specific combinations. How should the server express it supports a username class token with hmac-sha-1 as well as a delegation class token with hmac-sha-256 or hmac-sha-1? I am not sure what's the right way to segment all this. But I know that it cannot be limited to just a choice of crypto.

EHL

> From: Hubert Le Van Gong [mailto:[email-masked]]
> Sent: Sunday, December 06, 2009 3:32 AM
> To: Stephen Farrell
> Cc: Eran Hammer-Lahav; OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] Including token class in authenticated requests
> 
> Talking of token classes/types then we probably should reuse names that
> already exist like: username token, binary token (similar I think to the
> opaque one mentioned so far) and XML token.
> 
> Hubert
> 
> 
> On Sun, Dec 6, 2009 at 12:13 PM, Stephen Farrell <[email-masked]>
> wrote:
> >
> >
> >> provide it. Future extensions defining new token classes (and I
> >> expect a few proposals before we are done with this work) can easily
> >> it must have it either way since it picks the appropriate token based
> >> on the classes supported by the server, it is still incorrect to
> >> require the client to send wasteful information. On the other hand,
> >> this might be one of those optimizations that are just not worth the
> >> hassle, and the client can waste

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 6 Dec 2009 11:54:56 -0700

If it wasn't clear, I am trying to find the right level of abstraction... just listing the cryptographic method isn't enough, but I am not sure what else is needed. It may just be that the token scheme spec should only define a base set of methods and a placeholder class parameter for others to define, such as OAuth.

EHL

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Eran Hammer-Lahav
> Sent: Sunday, December 06, 2009 10:35 AM
> To: OAuth WG ([email-masked])
> * Cryptographic properties/method (the black box applied to the normalized
> request to produce some kind of verifiable value)
> I used the term class to identify the combination of these token properties. I
> agree that the proposed class names are confusing as they focus on only the
> cryptographic properties. But that can be solved with better names rather
> than a better term.
> 
> If all tokens were server-issued, the server would simply provide a server-
> specific token name and provide the cryptographic method to be used with
> it. For example, when the server issues a token, it will say:
> 
> Why do we need a name? We need something to tell the client which token
> to use, and it should not be limited to just the cryptographic method used.
> This is the existing problem in Basic and Digest and why we need to define a
> new scheme which greatly overlaps them. They do not support any other
> classes of tokens other than username (yes, they can be used with other
> classes but only in a fully controlled client-server environment, not the real
> world).
> 
> The problem with a server-picked name, is that it only works with server-
> issued tokens. It is very likely that in the (near) future someone will want to
> define a self-issued token using PKI or other means. That requires the server
> to be able to express what it supports with something other than a server-
> picked name.
> 
> We can break all the properties into separate attributes. The problem with
> that is it requires the ability to declare specific combinations. How should the
> server express it supports a username class token with hmac-sha-1 as well as
> a delegation class token with hmac-sha-256 or hmac-sha-1? I am not sure
> what's the right way to segment all this. But I know that it cannot be limited
> to just a choice of crypto.
> 
> EHL
> 
> > that already exist like: username token, binary token (similar I think
> > to the opaque one mentioned so far) and XML token.
> >
> > Hubert
> >
> >
> > >> the token (e.g. hmac-sha-1, hmac-sha-256,
> > > That's just confusing. The examples are mac/signature schemes. If
> > > you want token classes something else is needed. What is "token class"
> > > supposed to mean?
> > > S.
> > >
> > >>
> > >> The question is, is it necessary for the client to inform the
> > >> server back which token class it is using? Whether the server
> > >> issued the token, or supports token classes issued by another
> > >> entity (the client, third party, etc.), it is should be pretty easy
> > >> for the server to know the properties of the token, simply by
> > >> looking up the
> > token identifier.
> > >>
> > >> (and I expect a few proposals before we are done with this work)
> > >> can easily accommodate the need to identify the token class from
> > >> the token
> > identifier.
> > >>
> > >> worth the hassle, and the client can waste