Subject: [OAUTH-WG] operational security

From: Brian Eaton <[email-masked]>
Date: Thu, 18 Feb 2010 12:35:34 -0800

On the call people wanted me to clarify what I meant when I talked
about operational security.  In a nutshell, I mean:

- what systems and what people have access to long-lived secrets?
   Keep this to a reasonable level, where reasonable is defined by
different use cases.

- what systems and what people have access to shorter-lived secrets?
   Repeat above caveat about reasonable protection.

- how are those secrets protected?
   Repeat above caveat about reasonable protection.

- deal with practical considerations of systems that people really build.
   Issues like latency, scalability, functionality, and complexity
impact all of the above.

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 18 Feb 2010 21:02:39 -0700

Can you apply this (without too much detail) to both WRAP and OAuth 1.0a? I think it would be useful to see how each comply with these goals (which look pretty important to me).

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Eaton
> Sent: Thursday, February 18, 2010 12:36 PM
> To: [email-masked]
> Subject: [OAUTH-WG] operational security
> 
> On the call people wanted me to clarify what I meant when I talked about
> operational security.  In a nutshell, I mean:
> 
>    Keep this to a reasonable level, where reasonable is defined by different
> use cases.
> 
>    Issues like latency, scalability, functionality, and complexity impact all of the
> above.
> 
> Cheers,
> Brian
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Eaton <[email-masked]>
Date: Thu, 18 Feb 2010 21:51:00 -0800

On Thu, Feb 18, 2010 at 8:02 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> Can you apply this (without too much detail) to both WRAP and OAuth 1.0a? I think it
> would be useful to see how each comply with these goals (which look pretty important to me).

In OAuth 1.0a, every system that needs to create or verify signatures
needs access to long-lived secrets.

This gives implementers a choice:
- let all their machines have those secrets, which increases attack surface
- add more RPCs (and thus latency and availability headaches) to every request

OAuth 1.0a also encourages servers to keep secrets in plaintext, which
creates exposure from other directions.  There may be some tricks you
can do to avoid this, but they are non-trivial.  (I'm not even sure
they would work, haven't thought them through entirely.)

Token revocation in OAuth 1.0a is also tricky, as it forces another
database lookup on every request.

WRAP doesn't do those things.

(Not saying this is the end-all/be-all of security for WRAP or OAuth.
Just additional security considerations.)

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 18 Feb 2010 22:56:18 -0700

I understand the removal of the client credentials for accessing resources. That's one less set of credentials accessible by all servers which we already have consensus. And by not having signatures, there are no secrets to verify.

But isn't the bearer token itself a sort of plain text secret?

I think what this brings up is the need for an HMAC / symmetric secret option because it is not clear what benefits it really offers over bearer token with SSL/TLS.

EHL

> From: Brian Eaton [mailto:[email-masked]]
> Sent: Thursday, February 18, 2010 9:51 PM
> To: Eran Hammer-Lahav
> Cc: [email-masked]
> Subject: Re: [OAUTH-WG] operational security
> 
> > Can you apply this (without too much detail) to both WRAP and OAuth
> > 1.0a? I think it would be useful to see how each comply with these goals
> (which look pretty important to me).
> 
> In OAuth 1.0a, every system that needs to create or verify signatures needs
> access to long-lived secrets.
> 
> creates exposure from other directions.  There may be some tricks you can
> do to avoid this, but they are non-trivial.  (I'm not even sure they would
> work, haven't thought them through entirely.)
> 
> Token revocation in OAuth 1.0a is also tricky, as it forces another database
> lookup on every request.
>

---

From: Brian Eaton <[email-masked]>
Date: Thu, 18 Feb 2010 22:09:08 -0800

> But isn't the bearer token itself a sort of plain text secret?

Yes, it is.

The WRAP access token is short-lived, which mitigates some of the
risks.  Also note that servers do not need to store access tokens at
all.

The WRAP refresh token is long-lived, but it does not need to be
stored in plain-text on the server.  You don't end up creating massive
databases of credentials server-side.  (Clients that hold lots of
refresh tokens still need them in plain text, unfortunately.)

The WRAP refresh token only needs to be accessible to a limited number
of systems.  So you can use that to improve the client-side security.

There are WRAP profiles that leverage existing trust relationships to
eliminate the need for refresh tokens entirely.

Cheers,
Brian

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 19 Feb 2010 09:10:33 +0100

Hi Brian,
> On Thu, Feb 18, 2010 at 9:56 PM, Eran Hammer-Lahav<[email-masked]>  wrote:
>    
Is this the point where OpenID and OAuth converge?

regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 19 Feb 2010 15:35:25 +0100

....
> I am completely missing the relation to OpenID here...  What is it?
>
Suppose a webite wants to (1) login users interactively and (2) access 
web services on behalf of those users which are secured by tokens. From 
my point of view, one could integrate token issuance into the login 
process. So the application might perform login via Openid and request 
access tokens as additional results of the login process from the 
identity provider. Does this make sense?

regards,
Torsten.

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 19 Feb 2010 08:53:28 -0500

Igor

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 19 Feb 2010 13:15:55 -0500

I have no doubt that the description makes sense, but I have not quite 
grasped it.  I think that what you mean is the case when I want to get 
to a web site (relying party) with an OpenID. Here I should get from the 
identity provider (after it authenticates me) not only an assertion to 
pass back to the relying party but also a token.

But what I don't understand is what access rights will this token give 
me. Is that that my identity provider is expected to know what access 
rights I have on different sites? This is the part that I am lost in.

Maybe it would be easy to explain this idea by applying it to the 
classical OAuth use case (i.e., getting a printing service to print my 
photos on a photo album site)?

If there is something written on this case, maybe you could share it?

I am actually very interested in this subject and glad that you brought 
it up.

Igor

Torsten Lodderstedt wrote:
> web services on behalf of those users which are secured by tokens. 
> From my point of view, one could integrate token issuance into the 
> login process. So the application might perform login via Openid and 
> request access tokens as additional results of the login process from 
> the identity provider. Does this make sense?
>
> regards,
> Torsten.
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 21 Feb 2010 15:55:23 +0100

Hi Igor,
> to a web site (relying party) with an OpenID. Here I should get from 
> the identity provider (after it authenticates me) not only an 
> assertion to pass back to the relying party but also a token.
>
> I am actually very interested in this subject and glad that you 
> brought it up.
I didn't have anything in my pocket when I asked Brian regarding 
convergence of OpenId and OAuth. It was just an idea coming into my 
mind, when he pointed out the security risk imposed by storing tokens in 
a Oauth client. OAuth is great in that it eliminates the need to handle 
user passwords on consumer sites, the same objective can be achieved 
when using OpenId for web site login. So combining OAuth with OpenId for 
this category of applications might be beneficialy.

And you are right, the key is the relationship between OpenId OP and 
OAuth Autorization Server the target services trust in. Below I 
summarize two possible setups. Note it is more brainstorming then 
thought through in detail. (I intentionally left out some details about 
privacy and security).

*strong coupling
In the simplest case, the photo album site is offered by a large service 
provider, which offers many different sites (products) to users. In 
order to offer a seamless user experience and facilitate security for 
web applications, the service provider uses a central user/authorization 
data management and a SSO server based on OpenId. So in comparison to 
classical OpenId, the OpenId protocol is used under the hood but the 
only OP supported for web site login is the provider's OP. Web service 
access is secured using OAuth tokens. Tokens are issued by a single 
OAuth service for all sites, which also operate on the central 
user/authorization data management.

The provider also offers a photo print service to its customers, which 
is bound to the providers photo album site. Login at the photo print 
service could be performed as follows:

1) Photo print service initiates authentication and passes an additional 
parameter, which identifies the required service (photo album)
2) OP authenticates the user
3) OP shows user consent page. In this case not only asking for the 
approval to send attributes but also permissions to the RP
4) OP has access to user data base and directly creates tokens (it could 
delegate this part to the OAuth service, too)
5) Tokens are sent back with the response to the photo print service

Such a strong coupling can be found in the environment I currently work in.
Benefits: the typical benefits expected by standards (maturity, 
know-how, libraries,...), it would especially simplify the the 
implementation of both web services and applications and decrease cost.

*loose coupling
Let's try now to generalize the idea a bit.
Assumptions:
- the photo album site uses OpenId and operates a OAuth service
- the photo print service site uses OpenId as well
- users can use any OpenId server they like for both services as long as 
the use the same OpenId for both services
- OAuth user consent pages shall be delivered by the OAuth server 
because of user recognition

1) Photo print service initiate authentication, passes additional 
parameters, which identify the required realms and services
2) OP authenticates the user
3) OP shows usual user consent page (attributes).
4) OP looks up OAuth provider associated with target web services (e.g. 
using YADIS/XRDS)
5) OP sents request to oauth provider along with the authenticated openid
Note: there has to be a trust relationship between OAuth server and 
OpenId OP. I see different options here: pre-shared secrets, something 
based on OpenId discovery, probably the registration free process based 
on public key as suggested by Eran (posting from 02/19/2010)
6) OAuth server looks up its database for a user associated with the 
given openid
7) If the user exists, the OAuth responds with a redirect URL for the 
tokens authorization process
8) OP redirects user browser to OAuth server
9) OAuth server requests users approval for photo print service
  + asks the user to allow the OpenID OP to automatically request tokens 
for the photo print service in future authentication transactions
10) OAuth server creates tokens and encrypts them using the photo 
service consumer_secret (prevents eavesdropping by OP and on transit)
+ OAuth server issues a token to the OpenId server to be used for 
further tokens acquisitions (based on the approval in step 9+)
11) OAuth redirects user browser back to OpenId OP along with the 
encrypted token(s)
12) OP redirects user browser back, the response contains the usual 
OpenId parameters + the OAuth tokens

What do you think?

regards,
Torsten.
>> Suppose a webite wants to (1) login users interactively and (2) 
>> access web services on behalf of those users which are secured by 
>> tokens. From my point of view, one could integrate token issuance 
>> into the login process. So the application might perform login via 
>> Openid and request access tokens as additional results of the login 
>> process from the identity provider. Does this make sense?
>>
>> regards,
>> Torsten.
>>