Subject: [kitten] OAUTH SASL and Channel binding

From: William Mills <[email-masked]>
Date: Fri, 10 Aug 2012 11:36:15 -0700 (PDT)

Given Simon's recent comments about the fundamental flaw in the idea of channel binding when you don't have an integrity guarantee,, as in the Bearer token use case, should channel binding remain in the OAuth SASL profile?

Thanks,

-bill

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 10 Aug 2012 18:39:43 +0000

On 8/10/12 2:36 PM, "William Mills" <[email-masked]> wrote:

>Given Simon's recent comments about the fundamental flaw in the idea of
>channel binding when you don't have an integrity guarantee,, as in the
>Bearer token use case, should channel binding remain in the OAuth SASL
>profile?

If you can never have an integrity guarantee, probably not, but I wouldn't
personally use such a mechanism in any case, so probably moot.

-- Scott

---

From: William Mills <[email-masked]>
Date: Fri, 10 Aug 2012 11:54:12 -0700 (PDT)

You could have an integrity guarantee for a signed profile like MAC or OAuth 1.0a.

>________________________________
> From: "Cantor, Scott" <[email-masked]>
>To: William Mills <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Friday, August 10, 2012 11:39 AM
>Subject: Re: [kitten] OAUTH SASL and Channel binding
>

---

From: Nico Williams <[email-masked]>
Date: Fri, 10 Aug 2012 13:55:30 -0500

> Bearer token use case, should channel binding remain in the OAuth SASL

I find it truly sad that OAuth 2.0 is only a bearer token system.
Channel binding is still possible, but since bearer tokens depend so
utterly on the TLS server PKI, channel binding adds... no value.

But, IMO, bearer tokens are a waste of time.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 10 Aug 2012 13:58:50 -0500

> You could have an integrity guarantee for a signed profile like MAC or OAuth

But that's not OAuth 2.0...

Nico
--

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 10 Aug 2012 19:05:40 +0000

>I find it truly sad that OAuth 2.0 is only a bearer token system.

I believe the MAC pieces in 2.0 still would permit it. I don't happen to
think they'll get implemented and used properly, but that's a separate
argument. I would like to see the specs built on OAuth get done in a way
that at least allows them to be done securely when the will exists.

> utterly on the TLS server PKI, channel binding adds... no value.

Not quite (in the abstract, maybe not here). One of the benefits in the
SAML case is that it provides a very nice way to offload TLS server
credential verification from the client (where it will be botched) to the
IdP (where it can be done via SAML metadata and PKIX told to go get
stuffed).

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Fri, 10 Aug 2012 14:38:34 -0500

> IdP (where it can be done via SAML metadata and PKIX told to go get

Oh, good point, but, of course, that requires changes to the HTTP/TLS
stack plumbing (since you want the client to not bother validating the
server cert the normal way on account of the bearer token mechanism
being about to do so via its interactions with the IdP).

Nico
--

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 10 Aug 2012 19:50:11 +0000

>being about to do so via its interactions with the IdP).

Yes, that's true. There are extant examples of that, and not just in C,
but less so as you get more scripty.

Anyway, not trying to go off topic. My opinion as an observer is that it
would be nice if the MAC or whatever non-bearer approaches within OAuth
could be used with channel binding even if it's not possible in the bearer
case. If it actually is. The SAML EC bearer case still supports channel
binding but that's because you can sign requests and responses and still
be using bearer tokens.

-- Scott

---

From: William Mills <[email-masked]>
Date: Fri, 10 Aug 2012 14:13:41 -0700 (PDT)

The SASL profile will support OAuth 1.0a just fine.

> From: Nico Williams <[email-masked]>
>To: William Mills <[email-masked]> 
>Cc: "Cantor, Scott" <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Friday, August 10, 2012 11:58 AM

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 11 Aug 2012 09:43:37 +0200

Which brings up another question: Is the SASL mechanism intended to
apply to both OAuth 2.0 and OAuth 1.0?  If that is the intention, I
think this should be clear from the introduction and throughout the
document.  This poses some challenges though, since the OAuth 1.x and
OAuth 2.x terminology and semantics differs somewhat.

I'm working on an implementation, and I've gone back and forth between
using libraries for OAuth 1.x and Oauth 2.x.

/Simon

William Mills <[email-masked]> writes:

> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: William Mills <[email-masked]>
Date: Sat, 11 Aug 2012 09:15:51 -0700 (PDT)

Early on there was resistance from folks to mentioning OAuth 1.0a because "there's no point, OAuth 1.0a is dead".  I can add the text back in easily.  Given the arguments about reviving the MAC draft in the OAuth WG I could change the MAC examples out to OAuth 1.0a so this draft relies on a finalized spec instead. 

Do people like that?  Hate it?

> From: Simon Josefsson <[email-masked]>
>Sent: Saturday, August 11, 2012 12:43 AM
>Subject: Re: OAUTH SASL and Channel binding
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 11 Aug 2012 19:53:21 +0300

I would not worry about OAuth 1.0 since the functionality we want in SASL OAuth is much better supported by OAuth 2.0.

---

From: William Mills <[email-masked]>
Date: Sat, 11 Aug 2012 10:08:57 -0700 (PDT)

That's arguable.  I have use cases where without MAC actually being available as a draft (which it's expired right now) where I want a signed token for integrations and the integration includes IMAP.  It's one of the reasons I've made sure OAuth 1.0a will work.  I also do actually want a signed example in the spec.

-bill

> From: Hannes Tschofenig <[email-masked]>
>Cc: Hannes Tschofenig <[email-masked]>; Simon Josefsson <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Saturday, August 11, 2012 9:53 AM

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 11 Aug 2012 20:14:38 +0300

I should probably add a bit more text.

We don't need the MAC or PK-based signature mechanism since they are not 1:1 compatible with what we are doing in SASL. So, we can ignore them. In addition, the PK-based signature mechanism has the problem that it does not provide a story for how the client dynamically obtains the public / private key. In a nutshell it is undeployable. 

Depending on the timeline you have in mind we may either re-use the Bearer Token specification or wait for the current security discussions to settle to add a more secure mechanism. There may also be no harm to define our own security mechanism for presenting the access token to the resource server if we want channel binding and other security features added since those will not likely be used in the HTTPS environment due to TLS load balancers. 

An important part from the OAuth specifications we want is a mechanism for requesting an access token and to obtain the resource owners consent prior to that step. OAuth 2.0 provides a well-written specification for that. Additionally, there is a lot of deployment available. 

We may, however, indicate that we only want to support the 'Authorization Code' grant type and not the other grant types since they are not useful in our scenario.  

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 11 Aug 2012 20:16:40 +0300

I provided more details in a follow-up mail and I don't think there is value in "inheriting the OAuth 1.0 functionality" for the signature mechanism since it is not compatible with what we are doing here anyway. We have to write new normative text to explain what it means for this specific usage (which is so different from HTTP), then we have additional security needs (such as TLS with channel binding), so that it is easier to just write the text we want in the draft ourselves.

---

From: William Mills <[email-masked]>
Date: Sat, 11 Aug 2012 10:33:04 -0700 (PDT)

We fundamentally disagree on a number of things here.  As a practical matter we need to support the password grant.  

Please explain how MAC, or a signature mechanism, is not 1:1 compatible.  To me it seems a solid fit, it was part of the design.

I do not want to use this to define a new way of getting tokens or PKI or define new tokens that support channel binding.  This is specifically for leveraging the OAuth infrastructure which already defines much or all of this.

-bill

>To: Hannes Tschofenig <[email-masked]> 
>Cc: William Mills <[email-masked]>; Simon Josefsson <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Saturday, August 11, 2012 10:14 AM

---

From: William Mills <[email-masked]>
Date: Sat, 11 Aug 2012 18:01:10 -0700 (PDT)

I think we can make channel binding better, how about language something like "A server offering channel binding (OAUTH-PLUS) MUST only accept authorization profiles that include signing and can provide message integrity for the channel binding data, and specifically MUST NOT offer the Bearer or other profile with similar security properties."

>To: Nico Williams <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]> 
>Sent: Friday, August 10, 2012 12:50 PM

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 12 Aug 2012 20:10:46 +0300

Hi Bill, 

Thanks for the quick feedback.

I think you care about providing good security support for the SASL OAuth
specification as much as I do. Of course we also want to take the existing
deployment into consideration as well. These two aspects often do not line
up nicely (as I can tell you from my past experience in the identity
management field). 

So, how do we get there?

In order to use Oauth 1.0 you have to do several things to avoid security
disaster: 

1. Avoid using the plaintext signature type without TLS. The IESG required
this in the published RFC but the deployment reality may look different.
2. Use TLS when obtaining a the MAC shared key for usage with the MAC
"authentication". The description of TLS for the client-to-authorization
server interaction is actually quite fuzzy since the main motivation for TLS
support in Oauth was to support client deployments that don't want to
support TLS (for performance reasons ‹see my recent mail to the Oauth
mailing list with a pointer to an old slide set).
3. Avoid using PK-based authentication from Oauth 1.0 since it's description
is incomplete.

This essentially means that you are down to
1. using TLS with the authorization server and
2. either using the equivalent of bearer tokens (which is the plaintext
variant on top of TLS) or MAC tokens.

The MAC token variant allows us to skip TLS (with loss of confidentiality
protection of course; we also loose the ability to protect the entire
message exchange and authentication of the server) but then for the use case
you worry about TLS will have to be supported also for subsequent data
exchanges - accessing your emails using TLS is quite common these days. I
guess you may agree.

Ideally, we therefore want to have application layer security in addition to
TLS in order to provide the proper protection. The channel binding
discussion very much relates to aspect.

How many Oauth 1.0 deployments are actually fulfilling these requirements
out of the box? Not that many, I would say. Then, you also seem to demand
the support for WebFinger.

Let's assume you want to have something better than Bearer Tokens. So, what
should we do? There are three choices:

1. Focus on Oauth 1.0 only (since it has a MAC specification in there).
Then, you ignore all the Oauth 2.0 deployment that is out there, of which
there is a lot. That would be pretty bad IMHO.
2. Copy relevant parts from
http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01 (of which there
is almost no deployment).
3. Wait for the Oauth group to settle on a mechanism. May take time.

A difficult decision.

Which one do you pick?

On the "grant type" issue. The "Resource Owner Password Credentials" grant
type essentially requires the client to have the user's long-term username
and password (at least for obtaining the access token). In some sense this
is actually the use case that many wanted to avoid when using Oauth. Since
you are as concerned about security as myself I am wondering whether this is
OK for you? I think it is pretty bad.

In addition to the "Resource Owner Password Credentials" grant type there
are these other grant types:
* the client credentials grant type?
* the implict grant type?

Would you also like to support them?

Ciao
Hannes

PS: You may have noticed that the Oauth 1.0 security terminology is a bit
messed up. I am not sure whether we can avoid carrying it over to the Oauth
SASL specification. For example, the term "signature" is not correct if we
are talking about a MAC. The correct term would be (keyed) message digest.
The MAC algorithm, as defined in , RFC 5849, actually doesn't provide
authentication. It provides key confirmation, i.e. It shows that the client
had previously obtained a key from the authorization server but it does not
tell who the client is.

On 8/11/12 8:33 PM, "William (Bill) Mills" <[email-masked]> wrote:

> Please explain how MAC, or a signature mechanism, is not 1:1 compatible.  To
> me it seems a solid fit, it was part of the design.
> 
> I do not want to use this to define a new way of getting tokens or PKI or
> define new tokens that support channel binding.  This is specifically for
> leveraging the OAuth infrastructure which already defines much or all of this.
> 
> -bill
> 
> 
>>   
>>  
>>  
>>   
>> 
>> Cc: William Mills <[email-masked]>; Simon Josefsson
>> <[email-masked]>; "[email-masked]" <[email-masked]>
>> We don't need the MAC or PK-based signature mechanism since they are not 1:1
>> compatible with what we are doing in SASL. So, we can ignore them. In
>> addition, the PK-based signature mechanism has the problem that it does not
>> provide a story for how the client dynamically obtains the public / private
>> key. In a nutshell it is undeployable.
>> 
>> Depending on the timeline you have in mind we may either re-use the Bearer
>> Token specification or wait for the current security discussions to settle to
>> add a more secure mechanism. There may also be no harm to define our own
>> security mechanism for presenting the access token to the resource server if
>> we want channel binding and other security features added since those will
>> not likely be used in the HTTPS environment due to TLS load balancers.
>> 
>> An important part from the OAuth specifications we want is a mechanism for
>> requesting an access token and to obtain the resource owners consent prior to
>> that step. OAuth 2.0 provides a well-written specification for that.
>> Additionally, there is a lot of deployment available.
>> 
>> We may, however, indicate that we only want to support the 'Authorization
>> Code' grant type and not the other grant types since they are not useful in
>> our scenario.  
>> 
>> Ciao
>> Hannes
>> 
>>> > I would not worry about OAuth 1.0 since the functionality we want in SASL
>>> OAuth is much better supported by OAuth 2.0.
>>> > 
>>>> >> Early on there was resistance from folks to mentioning OAuth 1.0a
>>>> because "there's no point, OAuth 1.0a is dead".  I can add the text back in
>>>> easily.  Given the arguments about reviving the MAC draft in the OAuth WG I
>>>> could change the MAC examples out to OAuth 1.0a so this draft relies on a
>>>> finalized spec instead.
>>>> >>

---

From: William Mills <[email-masked]>
Date: Sun, 12 Aug 2012 20:31:11 -0700 (PDT)

For a complete solution for clients what I demand is auth endpoint discovery for standalone cleints.  Webfinger/SWD seems to solve my problem, it's functional and I can work with it.  I really *DO NOT CARE* how this problem gets solved, but it must be solved. 

Several more things:

-    OAuth 1.0a style credentials solve some problems for me because we have extant integrations that could use SASL/OAUTH profile immediately.
-    I don't want to solve OAuth 1.0a's problems in this draft.

-    I don't want to wait for MAC since it's now apparently going back to committee to be completely re-evaluated.

I'm willing to accept that we're going to have a number of compromises here.  Bearer tokens are only slightly better than cookies (because the browser as a confused deputy is sort of fixed).  OAuth 1.0a with plaintext (it is to laugh) secrets are similarly bad.  

I take it as fact that we will have additional signed OAuth 2 profiles, and so I want to provide examples for this type of profile.  I am not willing to make this incompatible with 1.0a or write it out of the spec as not allowed. 

In fact, while we shoudl make sure the draft isn't fundamentally broken, Like having channel binding wit bearer tokens whihc is useless, my intent is to punt all of the security considerations for using 1.0a or Bearer or JWT et al back ot those specs.

-bill

> From: Hannes Tschofenig <[email-masked]>
>To: William (Bill) Mills <[email-masked]>; Hannes Tschofenig <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]>; Simon Josefsson <[email-masked]> 
>Sent: Sunday, August 12, 2012 10:10 AM
>Re: [kitten] OAUTH SASL and Channel binding 
>Hi Bill, 
>
>I think you care about providing good security support for the SASL OAuth specification as much as I do. Of course we also want to take the existing deployment into consideration as well. These two aspects often do not line up nicely (as I can tell you from my past experience in the identity management field). 
>
>So, how do we get there? 
>
>In order to use Oauth 1.0 you have to do several things to avoid security disaster: 
>
>
>	1. Avoid using the plaintext signature type without TLS. The IESG required this in the published RFC but the deployment reality may look different.   
>	2. Use TLS when obtaining a the MAC shared key for usage with the MAC "authentication". The description of TLS for the client-to-authorization server interaction is actually quite fuzzy since the main motivation for TLS support in Oauth was to support client deployments that don't want to support TLS (for performance reasons —see my recent mail to the Oauth mailing list with a pointer to an old slide set). 
>	3. Avoid using PK-based authentication from Oauth 1.0 since it's description is incomplete.
>
>	2. either using the equivalent of bearer tokens (which is the plaintext variant on top of TLS) or MAC tokens. 
>
>The MAC token variant allows us to skip TLS (with loss of confidentiality protection of course; we also loose the ability to protect the entire message exchange and authentication of the server) but then for the use case you worry about TLS will have to be supported also for subsequent data exchanges - accessing your emails using TLS is quite common these days. I guess you may agree. 
>
>Ideally, we therefore want to have application layer security in addition to TLS in order to provide the proper protection. The channel binding discussion very much relates to aspect.
>
>How many Oauth 1.0 deployments are actually fulfilling these requirements out of the box? Not that many, I would say. Then, you also seem to demand the support for WebFinger.
>
>Let's assume you want to have something better than Bearer Tokens. So, what should we do? There are three choices:
>
>
>	1. Focus on Oauth 1.0 only (since it has a MAC specification in there). Then, you ignore all the Oauth 2.0 deployment that is out there, of which there is a lot. That would be pretty bad IMHO. 
>	2. Copy relevant parts from http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01 (of which there is almost no deployment). 
>On the "grant type" issue. The "Resource Owner Password Credentials" grant type essentially requires the client to have the user's long-term username and password (at least for obtaining the access token). In some sense this is actually the use case that many wanted to avoid when using Oauth. Since you are as concerned about security as myself I am wondering whether this is OK for you? I think it is pretty bad. 
>
>In addition to the "Resource Owner Password Credentials" grant type there are these other grant types: 
>
>PS: You may have noticed that the Oauth 1.0 security terminology is a bit messed up. I am not sure whether we can avoid carrying it over to the Oauth SASL specification. For example, the term "signature" is not correct if we are talking about a MAC. The correct term would be (keyed) message digest. The MAC algorithm, as defined in , RFC 5849, actually doesn't provide authentication. It provides key confirmation, i.e. It shows that the client had previously obtained a key from the authorization server but it does not tell who the client is.  
>
>
>>>  From:Hannes Tschofenig <[email-masked]>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 15 Aug 2012 08:35:52 +0300

Hi Bill, 

you may be surprised to hear that there is not that much difference between the different security mechanisms. See an early writeup I made when we had the discussions on the OAuth list in 2010. Not that anyone had ever read my draft but here it is:
http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt

(What is not mentioned in the draft is that bearer and the MAC token is equally insecure when using a client that is unable to keep a secret confidential.)

Anyway, I presented three choices in my previous mail to you about the next possible steps and I didn't understood which one you picked:

> 	• Focus on Oauth 1.0 only (since it has a MAC specification in there). Then, you ignore all the Oauth 2.0 deployment that is out there, of which there is a lot. That would be pretty bad IMHO.
> 	• Copy relevant parts from http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01 (of which there is almost no deployment).
> 	• Wait for the Oauth group to settle on a mechanism. May take time. 

Ciao
Hannes

On Aug 13, 2012, at 6:31 AM, William Mills wrote:

> 	• Avoid using the plaintext signature type without TLS. The IESG required this in the published RFC but the deployment reality may look different.  
> 	• Use TLS when obtaining a the MAC shared key for usage with the MAC "authentication". The description of TLS for the client-to-authorization server interaction is actually quite fuzzy since the main motivation for TLS support in Oauth was to support client deployments that don't want to support TLS (for performance reasons —see my recent mail to the Oauth mailing list with a pointer to an old slide set).
> 	• Avoid using PK-based authentication from Oauth 1.0 since it's description is incomplete.
> 
> 	• using TLS with the authorization server and
> 	• either using the equivalent of bearer tokens (which is the plaintext variant on top of TLS) or MAC tokens. 
> 
> 	• Focus on Oauth 1.0 only (since it has a MAC specification in there). Then, you ignore all the Oauth 2.0 deployment that is out there, of which there is a lot. That would be pretty bad IMHO.
> 	• Copy relevant parts from http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01 (of which there is almost no deployment).
> 	• Wait for the Oauth group to settle on a mechanism. May take time. 
> 
> A difficult decision. 
> 
> Which one do you pick? 
> 
> 	• the client credentials grant type?
> 	• the implict grant type? 
>

---

From: William Mills <[email-masked]>
Date: Tue, 14 Aug 2012 22:58:37 -0700 (PDT)

Sure, if you can't keep a secret you're done, there's no secure model.  I think you're talking an edge case and generalizing that, saying "if we have no client confidentiality then all things are equally insecure". Is that truly worth considering?  

The advantages of MAC and 1.0a over Bearer when you CAN keep a secret are: that you can make securely authorized protected resource transactions without TLS or other transport security, and that the client requires 2 pieces of information (token and secret) which can be stored separately.  Are you arguing that MAC and Bearer are equivalent when the clients cankeep a secret?

-bill

> From: Hannes Tschofenig <[email-masked]>
>Cc: Hannes Tschofenig <[email-masked]>; Hannes Tschofenig <[email-masked]>; "[email-masked]" <[email-masked]>; Simon Josefsson <[email-masked]> 
>Sent: Tuesday, August 14, 2012 10:35 PM

---

From: Nico Williams <[email-masked]>
Date: Wed, 15 Aug 2012 11:34:17 -0500

> (What is not mentioned in the draft is that bearer and the MAC token is equally insecure when using a client that is unable to keep a secret confidential.)

The fatal flaw in all of our security protocols is that we assume
local security.  From a protocol perspective it's not clear how we can
possibly do better: given local security we can build network security
with relative ease, but we don't know how to do the reverse.

So we assume local security.  Which means that we can't consider a
bearer token system and a "MAC token" system as equivalents.  And we
should want to have a MAC token, not a bearer token.

Nico
--

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 16 Aug 2012 09:50:27 +0300

I do not believe that the term "equivalent" is appropriate here since the mechanisms we are discussing provide different security properties. The question we always had been struggling with was "what are the desired security properties given certain deployment constraints". 

I personally do not have a particular preference for one or the other security mechanisms. I had looked at them and compiled a writeup in draft-tschofenig-oauth-signature-thoughts-00.txt when the initial discussions surfaced. What I am not happy with are statements such as "I like mechanism X" without actually knowing why someone likes it. Even worse is the case when bogus arguments are being presented. Some folks, for example, have always been arguing against TLS (because they consider it broken). While that may be a popular thought it does not help when the same security mechanism requires TLS to be used between the client and the authorization server. I would at least demand that the line of argument is consistent for the entire protocol -- not just for one communication leg. 

So, my exercise has been to find out what properties and constraints people have when they say "I like mechanism X". 

I hope that this makes sense.

---

From: Nico Williams <[email-masked]>
Date: Thu, 16 Aug 2012 02:08:46 -0500

> I do not believe that the term "equivalent" is appropriate here since the mechanisms we are discussing provide different security properties. The question we always had been struggling with was "wh…

I said they weren't equivalent.  But, at any rate, let's look at properties:

 - both bearer tokens and "signature tokens" (let's call them that for
argument's sakes) can authenticate a client to a service

 - bearer tokens cannot authenticate a service to a client, but by
using TLS and validating the cert at the token issuer a bearer token
system can still authenticate the service to the client; the same
applies to signature mechanisms if they use a half round trip

 - both can do channel binding, though in the case of the bearer token
it's practically the same thing as authenticating the server

 - both can exchange session keys if they should be desired, but
bearer tokens can only do this with TLS

 - bearer tokens *must* be used with TLS, whereas signature tokens can
be used with and without TLS (the whole world is not web/HTTP, so this
is of some importance)

 - both require cryptography somewhere; bearer tokens require it in
TLS and between the client and the token issuer.

Is that about right?  I think you could make an argument that bearer
tokens are not so bad, but I would argue that they are not so general.

Nico
--

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 16 Aug 2012 10:36:52 +0300

Hi Nico, 

> I said they weren't equivalent.  But, at any rate, let's look at properties:

The OAuth entities are: client (which may be a Web site, or a downloadable application, a JavaScript application running in your browser, etc.) and the resource server. I believe you call the resource server the "service". Note that we are not at all talking about the resource owner her (which is the user granting access to the protected resource). 

> argument's sakes) can authenticate a client to a service

Actually neither of them authenticates the client to the resource server. Client authentication is a separate mechanism independent of the discussed security mechanisms in the spec. 

> applies to signature mechanisms if they use a half round trip

When I talk about "Bearer Tokens" then I refer to the entire specification rather than about the token itself. 

As such, I would say that bearer tokens provide authentication of the resource server to the client via the help of the TLS using PK-based authentication. 

> it's practically the same thing as authenticating the server

If we are talking about the currently defined OAuth mechanisms (and not about the ideas we toss around in the OAuth SASL spec) then I have to say that channel binding is not defined for either one of them. 
With MAC TLS is not used for the client-to-resource server interaction (but at least theoretically has to be used when obtaining the shared secret and the token from the authorization server -- even though this is vaguely specified). 
With the Bearer Token spec the token is not linked to the underlying TLS authentication in any way. In fact I believe with existing TLS APIs this could be quite tricky.  

> bearer tokens can only do this with TLS

True. 

> be used with and without TLS (the whole world is not web/HTTP, so this

Yes, bearer tokens must be used with TLS. 
TLS is not only used in the Web.
> TLS and between the client and the token issuer.
Bearer tokens require TLS between the client and the authorization server (to obtain the token) and between the client and the resource server (when presenting the token). 

MAC tokens require (in my opinion - but not in the spec) TLS between the client and the resource server (to obtain the token and the shared secret) but not between the client and the resource server (unless confidentiality protection, integrity protection of the entire message exchange, or server-side authentication is a desire). Then, there is also the step where the shared secret needs to travel from the authorization server and the resource server. When you replace the terms s/authorization server/identity provider and s/resource server/relying party then you may see the need to have a solution for cross domain communication. 

> tokens are not so bad, but I would argue that they are not so general.
Yes, about right. 

Ciao
Hannes

---

From: Nico Williams <[email-masked]>
Date: Thu, 16 Aug 2012 10:03:41 -0500

> The OAuth entities are: client (which may be a Web site, or a downloadable application, a JavaScript application running in your browser, etc.) and the resource server. I believe you call the resou…

I was trying to address bearer vs. not-beader token mechanisms in
general, not OAuth specifically.

> Actually neither of them authenticates the client to the resource server. Client authentication is a separate mechanism independent of the discussed security mechanisms in the spec.

See above.  They authenticate something.  Whether that something be an
assertion of identity or an assertion of access to resources.

> As such, I would say that bearer tokens provide authentication of the resource server to the client via the help of the TLS using PK-based authentication.

In particular it's very difficult for bearer token systems to do
better than the TLS PKI for server authentication.  Scott talked about
how it can be done, but I'm skeptical.  This, and the requirement for
transport security being up before the token is sent, are the biggest
problems with bearer tokens IMO.

...
> TLS is not only used in the Web.

More importantly: TLS is not used in every application protocol.
Examples where it's not used:

 - SSHv2
 - NFSv4 (and all ONC RPC apps)
 - AFS (and all rx apps)
 - SMB
 - all MSRPC apps
 - DNS updates

> MAC tokens require (in my opinion - but not in the spec) TLS between the client and the resource server (to obtain the token and the shared secret) but not between the client and the resource serve…

That step can be Needham-Schroeder-like (i.e., like Kerberos).

>> tokens are not so bad, but I would argue that they are not so general.

Maybe we should write this down somewhere.

Nico
--

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 16 Aug 2012 15:08:53 +0000

>problems with bearer tokens IMO.

Something apropos of this that addresses something Hannes mentioned: while
it is true that you may still need TLS on the other traffic legs even if
you do holder of key tokens, that leg between the client and the
authorization server (in OAuth terms) or in the case of SAML, the IdP, is
a much more restricted set of systems which you have to provision into the
client somehow anyway (unless you're just ignoring phishing).

In other words, it's more tractable to address that TLS leg in a more
advanced manner than it is to try and fix all the TLS usage between the
client and the relying parties, of which there are more, and which have no
general relationship to the user.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Thu, 16 Aug 2012 10:40:07 -0500

> client somehow anyway (unless you're just ignoring phishing).

Indeed, but that's not the leg I'm worried about.

Nico
--

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 17 Aug 2012 14:32:46 +0300

Hi Nico, 

> general, not OAuth specifically.

OK. 

> assertion of identity or an assertion of access to resources.

I think that there is a big difference between authenticating an entity vs. providing key confirmation. If you look at a number of three party protocols (think about EAP/AAA over foo, ABFAB, SAML, etc.) then there lots of differences and not surprisingly these details matter.

> better than the TLS PKI for server authentication.

The Bearer Token uses TLS for server-side authentication. 

>  Scott talked about
That's a great list but the question with regard to OAuth SASL is:

 * Are these applications in a need a new SASL security mechanism? Bill and myself focus on different applications. 
 * In case that these applications need a new SASL security mechanism, do they need something in the style of OAuth SASL? 
 * If they do, why cannot they implement whatever the OAuth SASL spec tells them to do. OAuth SASL does not require them to use TLS elsewhere in their protocol (even though it would probably make a lot of sense). 

> That step can be Needham-Schroeder-like (i.e., like Kerberos).

Yes.

> Maybe we should write this down somewhere.

You are right. 

I tried to do that in http://www.potaroo.net/ietf/all-ids/draft-tschofenig-oauth-signature-thoughts-00.txt. It seems that I have not done a good job. 

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 17 Aug 2012 14:41:21 +0300

> general relationship to the user.

I agree with you, Scott. 

Still, it does not make TLS a useless mechanism for the client-to-resource server interaction.

It ultimately depends on what we think different IdP providers are capable of providing. If we assume a model where "everyone" can run their own identity provider then we have to lower our expectations about their ability to configure security settings. 

Remember the OpenID days - that was the expectation that some people had raised. Everyone would run their own OpenID server. 

Is this what we are aiming for?

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 17 Aug 2012 16:25:55 +0000

>client-to-resource server interaction.

I consider it useless if the expectation is that the typical Web 2.0
developer's tools will get it right.

>It ultimately depends on what we think different IdP providers are
>capable of providing. If we assume a model where "everyone" can run their
>own identity provider then we have to lower our expectations about their
>ability to configure security settings.

There's a spectrum between a billion IdPs and 6. OAuth in practice is way
too far to the latter end for my taste.

But all this is really beside the point. I'd like to return to the
original question: is there a concern about having channel binding
specified if the OAuth profile permits it? And more to the point, it
sounds like the real problem is that there is no OAuth 2.0 material on the
road to standardization that will in fact support it.

-- Scott

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 17 Aug 2012 16:25:55 +0000

-- Scott

---

From: William Mills <[email-masked]>
Date: Fri, 17 Aug 2012 09:52:17 -0700 (PDT)

OAuth 1.0a can support it.  I've taken the MAC examples out of the OAUTH SASL draft and replaced them with OAuth 1.0a examples.  A new version will be coming soon with these changes, and I've moved the MAC draft to informative instead of normative.

-bill

>To: Hannes Tschofenig <[email-masked]> 
>Sent: Friday, August 17, 2012 9:25 AM

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 20 Aug 2012 15:01:34 +0300

Hi Scott, 

> developer's tools will get it right.

How are changes that a typical Web 2.0 developer is going to get anything security related right.
I believe I remember you saying that we have to focus on producing libraries that do not require the Web developer to understand these types of things. Do I remember that correctly?

> too far to the latter end for my taste.

I am not sure where our discussion is heading but here are my observations:

* Sharing protected data is common these days
* Providing security for this (other than sharing long-term credentials) is also important. 

How to get the long tail of Web developers who operate an IdP to run it correctly is the question. 

You are saying that they are not going to get TLS right. The problem is only that OAuth 1.0 and OAuth 2.0 rely on TLS for the client-to-authorization server interaction. 

What alternatives are you suggesting? 

> specified if the OAuth profile permits it?

I am in favor of having channel binding in there. 
I doubt that Web 2.0 developers will understand that value of it but that's a different story. 

> And more to the point, it

At the last meeting I have reinforced my desire to work on additional OAuth 2.0 security mechanisms and I had kicked off the discussion with a draft I had been working on. 

Ciao
Hannes

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 20 Aug 2012 13:39:00 +0000

On 8/20/12 8:01 AM, "Hannes Tschofenig" <[email-masked]> wrote:
>
>How are changes that a typical Web 2.0 developer is going to get anything
>security related right. I believe I remember you saying that we have to
>focus on producing libraries that do not require the Web developer to
>understand these types of things. Do I remember that correctly?

Yes. The Web 2.0 community has largely rejected that approach as far as I
can tell.

>correctly is the question.

I wouldn't let a typical web developer anywhere near an IdP (or much of
anything else). If you mean the people that would operate an IdP for a
typical enterprise or community, I agree, it's a problem, but I don't have
anything against outsourcing such functions either.

>You are saying that they are not going to get TLS right. The problem is
>only that OAuth 1.0 and OAuth 2.0 rely on TLS for the
>client-to-authorization server interaction.

TLS isn't really the problem, it's the PKI it tends to rely on and the
code that implements it. I think there are pieces of solutions around for
that, but I don't think they will get traction in the environments that
Web 2.0 cares about.

>What alternatives are you suggesting?

My alternatives have been rejected outside of my immediate community, so
I'm just continuing to wait out the latest cycle of reinvention and then
I'll see what comes out of the rubble. My only concern in this
conversation is that if I have to be stuck eventually, as a deployer, with
an OAuth solution for non-web, I'd like to see it not suck as much as
possible.

>At the last meeting I have reinforced my desire to work on additional
>OAuth 2.0 security mechanisms and I had kicked off the discussion with a
>draft I had been working on.

That's good.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Tue, 21 Aug 2012 17:03:11 -0500

> an OAuth solution for non-web, I'd like to see it not suck as much as

We can only have so many cycles of suck before we decide to do
something different, no?

I'm not optimistic about this cycle.  And yet HTTP/2.0 *is* the best
opportunity we'll have in a while *if* HTTP/2.0 really does gain
momentum, and the bigger the changes in HTTP/2.0 the more we can
justify on the security side (OTOH, the bigger the changes, the bigger
the chance of failure or exhaustion that leaves security unchanged).

But there is a way to make this happen: make implementations available
as a first step.  It may well be that nothing else helps.

Nico
--

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 22 Aug 2012 01:32:45 +0000

>We can only have so many cycles of suck before we decide to do

I probably haven't seen as many, so I don't know if that makes me more
pessimistic or optimistic.

>the chance of failure or exhaustion that leaves security unchanged).

I'm certainly interested in that, but I don't really think the drivers of
the web right now have a philosophy on much of anything that I would agree
with. Sucks for me.

>as a first step.  It may well be that nothing else helps.

When the ethos is that everything should be implemented from scratch all
the time, that model doesn't work as well.

-- Scott