Subject: [kitten] SASL OAuth - My Conclusion So Far

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 16 Aug 2012 12:54:21 +0300

Hi all, 

given the discussions on the list about the OAuth SASL mechanism I thought I would summarize my conclusions so far.

The current SASL OAuth specification offers a range of different security mechanisms, namely 
  * OAuth 1.0 MAC Token
  * OAuth 2.0 Bearer Token
    (On top of that there is the channel binding support as well). 

Of course it would be desirable to only have a single mechanism (or at least using the same foundation, such as OAuth 2.0) but the security properties of the two mechanisms seem to attract different groups. Bill definitely feels that MAC tokens are more secure than Bearer Tokens and he needs them for his use cases. 

In some sense the desire to have mechanisms with different properties shouldn't be all that surprising given that motivated the concept of authentication frameworks (like SASL, EAP, and GSS-API) altogether. 

Luckily, there is a built-in mechanism for negotiation between the SASL endpoints. The discovery mechanism to be used for the interaction with the authorization server has, unfortunately, not yet been standardized. 

I do not want to convince Bill that the Bearer Token mechanism is the only security mechanism he needs for his use cases. I even believe that we should extend the OAuth SASL specification as we make progress in the OAuth WG. 

Having said that I still appreciate any feedback, like the recent comment from Nico, that helps us making progress in the OAuth security discussions. 

Ciao
Hannes

---

From: Nico Williams <[email-masked]>
Date: Thu, 16 Aug 2012 09:43:22 -0500

> In some sense the desire to have mechanisms with different properties shouldn't be all that surprising given that motivated the concept of authentication frameworks (like SASL, EAP, and GSS-API) al…

I would say it's not about the framework but about the applications
that might use these mechanisms.  Not all are web/HTTP apps, nor are
all apps that use or can use TLS either.  No TLS almost implies no
bearer tokens.

Nico
--

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 16 Aug 2012 18:56:32 +0300

Hi Nico, 

> all apps that use or can use TLS either.  No TLS almost implies no

I  agree with you.

For applications that cannot use TLS (or DTLS) bearer tokens are not usable.

Ciao
Hannes

---

From: William Mills <[email-masked]>
Date: Thu, 16 Aug 2012 09:20:11 -0700 (PDT)

While I agree with you form a security stance, I must point out that FB was using bearer tokens in the clear for about a year I think until the rolled out HTTPS.  People will in fact make that choice, just as they use cookies for authorization in the clear.

>________________________________
> From: Hannes Tschofenig <[email-masked]>
>To: Nico Williams <[email-masked]> 
>Cc: [email-masked] 
>Sent: Thursday, August 16, 2012 8:56 AM
>Subject: Re: [kitten] SASL OAuth - My Conclusion So Far
> 
>Hi Nico, 
>
>_______________________________________________
>Kitten mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/kitten
>
>
>

---

From: Nico Williams <[email-masked]>
Date: Thu, 16 Aug 2012 12:21:53 -0500

On Thu, Aug 16, 2012 at 11:20 AM, William Mills <[email-masked]> wrote:
> While I agree with you form a security stance, I must point out that FB was
> using bearer tokens in the clear for about a year I think until the rolled
> out HTTPS.  People will in fact make that choice, just as they use cookies
> for authorization in the clear.

Cookies themselves are a form of bearer token, but at least one can
set different cookies for use with HTTP vs. HTTPS.  Bearer tokens are
too valuable to send without using TLS.  A signature token is far more
secure in the absence of TLS, but if you'll use HTTP and cookies w/o
TLS at all then your sessions can still be hijacked, in which case
bearer or signature makes little difference.

For me the main thing is that bearer tokens simply have no useful
existence w/o TLS or equivalent, which means they are not applicable
to a non-trivial class of application protocols.  I.e., bearer tokens
are less general.

There's also the problem that bearer tokens cannot improve server
authentication without rototilling the HTTP/TLS stacks.

Nico
--

---

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

Hi Bill, 

I fully understand that issue. The problem is that I do not believe that new standards with more sophisticated security mechanisms will help those people who do not want to use security to begin with. 

There are also many strange extensions for OAuth, and OAuth alike systems out there that are privacy invasive and have dubious security value. 

Ciao
Hannes

---

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

Hi Nico, 

On Aug 16, 2012, at 8:21 PM, Nico Williams wrote:

> set different cookies for use with HTTP vs. HTTPS.

I don't like this comparison with cookies to much since cookies are quite different. 

>  Bearer tokens are
> too valuable to send without using TLS.

Correct. That's why the specification mandates TLS. 

>  A signature token is far more
> secure in the absence of TLS,

In absence of TLS the shared secret for the keyed message digest is carried to the client in clear. Why is that more secure? 
If an attacker is supposed to eavesdrop the access token then why wouldn't he want to also get the key as well (which is in the same message)?

> but if you'll use HTTP and cookies w/o

Which application protocols are you particularly talking about that cannot use TLS (or DTLS)?

> authentication without rototilling the HTTP/TLS stacks.
Not sure what you mean. 

Just as a side-note: MAC tokens do not provide server authentication 

Ciao
Hannes

---

From: Nico Williams <[email-masked]>
Date: Sat, 18 Aug 2012 00:00:44 -0500

> I don't like this comparison with cookies to much since cookies are quite different.

Hannes, they are like bearer tokens in the way that matters in the
context that I was discussing.  I agree that there's other aspects of
cookies that make them apples to OAuth's being oranges, but that's not
relevant here.  Interjecting irrelevancies into the discussion only
makes it harder to make progress.

> Correct. That's why the specification mandates TLS.

And that's the problem I have: I don't think any service
authentication system that must scale to all services on the web can
provide the level of security that we should want.  I want security
mechanisms that support federations (retail federations, banking
federations, ...).  You and I disagree fundamentally on this.  At this
point it will have to be the market that proves one or both of us
wrong, because we've been at this enough that I don't think we'll
change each other's minds.

> In absence of TLS the shared secret for the keyed message digest is carried to the client in clear. Why is that more secure?

Kerberos doesn't use TLS and yet it works and securely exchanges keys.
 Ditto ABFAB.  Other mechanisms could use similar techniques to get
the same effect.  This isn't rocket science.

> Which application protocols are you particularly talking about that cannot use TLS (or DTLS)?

I gave you a list of some such protocols.

>> authentication without rototilling the HTTP/TLS stacks.

See my exchange with Scott earlier this week.

> Just as a side-note: MAC tokens do not provide server authentication

As I've said before, I'm talking in general here.  A
proof-of-possession mechanism most certainly can provide server
authentication.

Nico
--

---

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

Hi Nico, 

> makes it harder to make progress.

There is no mechanism for the client to request cookies. They are exclusively used by the server to store state on the client. 

Cookies may not need to be protected by TLS (neither set nor requested).
Cookies sharing works with the same origin policy. 
Cookies have no (technical mechanism) to obtain the consent of a resource owner. 
 
> change each other's minds.

I am not sure where our disagreement here is. 

We both think that federations are desirable and OAuth allows to build a WebSSO protocol as well (as the OpenID Connect folks are demonstrating). I also care about scalability. 

> the same effect.  This isn't rocket science.

When Kerberos was designed TLS didn't even exist. The comparison between TLS and Kerberos is inappropriate anyway since TLS is a two-party and Kerberos a three party protocol. 

ABFAB will have to use TLS in many cases (although maybe without server-side authentication). While I would love to see ABFAB deployed everywhere I have my doubts that it will happen in the Web application space. 

> I gave you a list of some such protocols.

Sorry; saw it a little later only. 

> See my exchange with Scott earlier this week.

Will take a look. 

> proof-of-possession mechanism most certainly can provide server

I agree. However, this is not the OAuth 1.0 MAC token approach that Bill had put into the draft but rather a version that we would be coming up with for OAuth 2.0. 

Ciao
hannes

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 20 Aug 2012 08:39:03 -0400

> When Kerberos was designed TLS didn't even exist. The comparison between TLS and Kerberos is inappropriate anyway since TLS is a two-party and Kerberos a three party protocol. 

TLS is a point to point protocol.   The authentication in TLS is in most
cases X.509 certificates.  When X.509 certificates are used, TLS
involves three parties: the TLS initiator, the TLS acceptor and the
Certificate Authority.

When Kerberos is used to authenticate TLS or other point to point
protocols, it has three parties: the initiator, the acceptor and the
KDC.  TLS can be authenticated with other mechanisms such as SRP which
are not three party systems, pre-shared keys (PSK), etc.

TLS itself is not an authentication mechanism.  It is a point to point
protocol that is used to add a security layer on top of a pre-existing
connection.  That security layer can add authentication an
authentication identity or it can be bound to an authentication identity
via channel bindings.

Authentication methods that do not support channel bindings to a
transport security protocol are of little interest to me because in my
opinion they cannot securely be used to avoid man-in-the-middle attacks.

Likewise, authentication methods that do not result in a shared key
between the initiator and the acceptor are of little interest to me
because such authentication methods cannot be used to key a transport
layer.  For example, providing the key to be used with TLS PSK or AFS RXGK:

  https://datatracker.ietf.org/doc/draft-wilkinson-afs3-rxgk/
  https://datatracker.ietf.org/doc/draft-wilkinson-afs3-rxgk-afs/

Jeffrey Altman

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 20 Aug 2012 16:58:47 +0300

Interesting interpretation of TLS with respect to the parties. 

But I agree nevertheless that we agree on the channel binding issue. I have no problems with channel bindings for non-HTTP-based protocols. 

And: Luckily we have no proposal on the table that does not lead to keys between the the initiator and the acceptor.

---

From: William Mills <[email-masked]>
Date: Mon, 20 Aug 2012 09:59:42 -0700 (PDT)

>I
 agree. However, this is not the OAuth 1.0 MAC token approach that Bill 
had put into the draft but rather a version that we would be coming up 
with for OAuth 2.0. 

How would an HoK scheme provide server authentication?  PKI?  

>Cc: Hannes Tschofenig <[email-masked]>; William Mills <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Monday, August 20, 2012 5:12 AM

---

From: Nico Williams <[email-masked]>
Date: Fri, 24 Aug 2012 16:43:10 -0500

TLS w/ PKI is too a three party protocol.  (Especially if CRLs are
checked / OCSP is used.)

There's quite a lot of duality between a symmetric key
Needham-Schroeder type protocol (e.g., Kerberos) and PKI.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 24 Aug 2012 16:54:13 -0500

> But I agree nevertheless that we agree on the channel binding issue. I have no problems with channel bindings for non-HTTP-based protocols.

The whole point of channel binding to TLS in any protocol that uses
TLS (including HTTPS) is to allow us to leverage whatever
authentication of the server to the client might be provided by the
authentication mechanism.  This then makes up for weakness in the TLS
server PKI (if it even gets used).

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 26 Aug 2012 18:38:45 +0200

Nico Williams <[email-masked]> writes:

>> But I agree nevertheless that we agree on the channel binding
>> issue. I have no problems with channel bindings for non-HTTP-based
>> protocols.
>

However, doesn't it works both ways?  If the TLS server PKI happens to
work, but the authentication mechanism is weak or prone to certain
attacks, having a channel binding might strengthen the solution.  Of
course, it depends on whether the authentication mechanism would detect
a channel binding mismatch.

/Simon

---

From: Nico Williams <[email-masked]>
Date: Sun, 26 Aug 2012 17:21:40 -0500

> a channel binding mismatch.

Kurt Zeilenga proposed a SCRAM-like mechanism that depends on the use
of tls-unique CB, using the CB data as the challenge, thereby shaving
a round trip.  So, yes, it's definitely possible to use CB to
strengthen a mechanism, but note that if server authentication in TLS
is weak or non-existent (e.g., because an anon DH cipher suite was
used) then the mechanism is not strengthened vis-a-vis active attacks.
 So the benefit of CB isn't entirely symmetric, no.

Nico
--

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 27 Aug 2012 09:28:31 +0300

> So the benefit of CB isn't entirely symmetric, no.

The Bearer Token spec does not permit TLS without server-side authentication. 
So, the anonymous DH cipher suite is not an option.