Fwd: FW: RSA P2P on Mash SSL

[Siddharth Bajaj]

 

For anybody at RSA conference, there is an On-demand peer-to-peer session on Mash SSL today at 2:10. This is in the Burgundy room 220 from 2:10 to 3:00 pm.

 

http://www.w3.org/2005/Incubator/MashSSL/

 

Thanks,

 

Siddharth

---

From: managemen...@cabforum.org on behalf of Ben Wilson
Sent: Tue 3/2/2010 2:48 PM
Subject: [cabfman]RSA P2P on Mash SSL

For any of you at RSA, there will be an On-Demand Peer-to-Peer meeting for anyone interested in Mash SSL.  It will be held in Burgundy 220 from 2:10 to 3:00 tomorrow.

Ben

 

Benjamin T. Wilson, JD CISSP
General Counsel and SVP Industry Relations
DigiCert, Inc.

Online: www.DigiCert.com
Email: b...@digicert.com
Toll Free: 1-800-896-7973 (US & Canada)
Direct: 1-801-701-9678
Fax: 1-866-842-0223 (Toll Free if calling from the US or Canada)

---

The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Thank You

 

[Mark Mcgloin]

Has some consideration been given to Wrap and long living processes?

I think the Refresh token may be intended to solve that, but I would like
to understand what additional security it provides over just an access
token with a long expiry. I can speculate but would like to hear the real
security considerations and intentions behind the refresh token

Mark McGloin

[Brian Eaton]

If you send long-lived access tokens to servers, those servers need to
constantly make RPCs to a central backend to check whether the user
has revoked access.

If you send short-lived access tokens that are periodically refreshed,
you reduce the number of calls you need to make to central backends.
The access tokens can be statically verified.

Cheers,
Brian

[Alan Karp]

Why do the servers need to continually check?  Can't they wait until they need to use the token before checking?  I would expect that long-lived tokens will be revoked rarely because people will use short-lived tokens if they anticipate a need to revoke. 

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
To post to this group, send email to oauth-...@googlegroups.com.
To unsubscribe from this group, send email to oauth-wrap-w...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.

[Brian Eaton]

On Wed, Mar 17, 2010 at 4:05 PM, Alan Karp <alan...@gmail.com> wrote:
> Why do the servers need to continually check?  Can't they wait until they
> need to use the token before checking?

Yes. Some systems need to optimize this check, and it's much easier
to optimize if the tokens are short-lived. Bloom filters and
cryptography both come in useful.

Cheers,
Brian

[Alan Karp]

Isn't as simple as

1. Attempt access presenting the long-lived token.
2. Token has been revoked.
3. Return 403 Forbidden.

If the token has been revoked, the request is going to fail anyway.  Is there some use case where reporting the failure doesn't work but detecting a potential failure does?

--------------
Alan Karp

Cheers,
Brian

[Alan Karp]

A colleague explained your answer to me in terms I can understand (baby talk, if you will).  My disconnect was that I had assumed that the authorization service would inform the service when one of its tokens was revoked.  It's clear from your answer that is not what is done.  Is there a reason you don't?

--------------
Alan Karp

On Wed, Mar 17, 2010 at 4:09 PM, Brian Eaton <bea...@google.com> wrote:

Cheers,
Brian

[Allen Tom]

Hi Alan,

One of the design goals  of WRAP was to clearly separate the Protected Resource from the Auth Server. In OAuth 1.0, the Protected Resource and Auth Server are a single entity called the Service Provider.

In an ideal world, Protected Resources can be very tightly integrated with their AuthZ service, which  allows Protected Resources  to verify the validity of an Access Token. If your architecture can support this, then you can use long lived Access Tokens, and skip the refreshing workflow. It would be a very good idea to require HTTPS to reduce the risk of long lived Access Tokens from getting compromised.

In a less than ideal world, Protected Resources might be loosely coupled to their Auth server, and it is not feasible to check the validity of an Access Token by checking a central auth service. In this case, implementers can work around this short coming by issuing short lived Access Tokens and defining a way for their Protected Resources to verify the Access Tokens locally.

Hope that helps,
Allen

To unsubscribe from this group, send email to oauth-wrap-w...@googlegroups.com <mailto:oauth-wrap-wg%2Bunsu...@googlegroups.com> .

[Alan Karp]

Thanks for your patience and clear reply, but I am still missing something.  

My understanding is that each token is for a specific Protected Resource, so I assumed the revocation request goes to the Protected Resource.  Even if the Auth Server is the one informed, it knows which Protected Resource to tell when a token is revoked.  Isn't that simpler than all the traffic of refreshing short-lived tokens or having the Protected Resource continually check?

--------------
Alan Karp

To unsubscribe from this group, send email to oauth-wrap-w...@googlegroups.com.

[Brian Eaton]

On Thu, Mar 18, 2010 at 4:49 PM, Alan Karp <alan...@gmail.com> wrote:
> My understanding is that each token is for a specific Protected Resource, so
> I assumed the revocation request goes to the Protected Resource.  Even if
> the Auth Server is the one informed, it knows which Protected Resource to
> tell when a token is revoked.

Imagine that the protected resource is a replicated service behind a
load balancer. Which of the umpteen machines do you tell that the
token is revoked? If you tell all of them, what do you do when one is
down or unreachable? Does every protected resource server keep track
individually of the issued tokens? How do you get them back in sync
when they disagree?

> Isn't that simpler than all the traffic of
> refreshing short-lived tokens or having the Protected Resource continually
> check?

No, it isn't. =)

Cheers,
Brian

[Dick Hardt]

To add to Brian's comments, the Auth Server may not even know which Protected Resources are using the Access Token. This allows a much more loosely coupled architecture that is claims based. A PR developer can set up a new PR, tell Client developers what Access Token they need, and no one needs to change config at the AS.

-- Dick

[Alan Karp]

On Thu, Mar 18, 2010 at 5:34 PM, Brian Eaton <bea...@google.com> wrote:
>
> Imagine that the protected resource is a replicated service behind a
> load balancer.  Which of the umpteen machines do you tell that the
> token is revoked?  If you tell all of them, what do you do when one is
> down or unreachable?  Does every protected resource server keep track
> individually of the issued tokens?  How do you get them back in sync
> when they disagree?
>

Since all requests go through the load balancer, that's the logical
place to record the revocation.  If checking against the list of
revoked tokens is too much work for the load balancer, it can make
sure all workers have a current copy of the list. I'm assuming that
relatively few tokens are long-lived and that they are rarely revoked.
If that assumption is wrong, then so am I.

--------------
Alan Karp

[Alan Karp]

Thanks for the explanation.  I had a completely different use model in mind.  I was thinking of the token as a capability that combined designation of the exact resource and the authorization to use it.  What you describe is more general, but I'm wondering if it might confuse users?

If I understand your model, Snapfish might choose to accept the same access token as flickr.  Will users understand the implications of sharing such a token?  Could that be the basis of an attack?  For example, someone might put up a game site that accepts gmail access tokens.  Having received the access token to allow the user to play a game, will the site then have access to the user's gmail account?

--------------
Alan Karp

[Brian Eaton]

On Fri, Mar 19, 2010 at 9:11 AM, Alan Karp <alan...@gmail.com> wrote:
> Since all requests go through the load balancer, that's the logical
> place to record the revocation.

Load balancers don't typically operate at this level.

> If checking against the list of
> revoked tokens is too much work for the load balancer, it can make
> sure all workers have a current copy of the list.

OK, let's assume
a) tokens never expire
b) but can be revoked
c) something keeps a list of all revoked tokens

That requires infinite storage. It's a CRL for certificates that never expire.

Cheers,
Brian

[Paul C. Bryan]

In response to this thread generally, I'd like to make a few
observations. Please correct me if I'm wrong.

1. If tokens are going to be contain signed material (such that an PR
can validate the token on its face against the resource(s) it's
protecting) then you're in the same problem space as PKI: trust,
certification, expiration, revocation, renewal.

2. If a token is meant to protect more than one resource, then there is
a scoping issue, as client and AS need to prearrange what resources it
will be requiring access to, in order to have the token scoped to those
resources.

3. If a token is going to be long-lived, you're going to need to handle
the case of' revoking a token to disable authorization should it be
invalidated before it is due to expire.

4. If a token is going to be short-lived, you're going to need to
refresh it frequently to maintain an active one, this will increase
overall burden on client and AS to handle frequently-issued,
properly-scoped access tokens.

5. If a PR is going to back-channel somewhere to check for token
revocation, you might as well just use a completely opaque token and
have the RP go back-channel to check its authorization against the
resources being requested (a la PEP-PDP model). This avoids a great deal
of the PKI (and scoping!) requirements that prima facie, STS-style token
validation incurs.

Paul

[Alan Karp]

On Fri, Mar 19, 2010 at 11:19 AM, Brian Eaton <bea...@google.com> wrote:
> On Fri, Mar 19, 2010 at 9:11 AM, Alan Karp <alan...@gmail.com> wrote:
>> Since all requests go through the load balancer, that's the logical
>> place to record the revocation.
>
> Load balancers don't typically operate at this level.
>

Good point. Still, server farms usually have some (logically) shared
storage, so any one of them can handle the revocation request and all
will know about it.

>
> OK, let's assume
> a) tokens never expire
> b) but can be revoked
> c) something keeps a list of all revoked tokens
>
> That requires infinite storage.  It's a CRL for certificates that never expire.

Nobody said anything about no expiration, just long-lived.

--------------
Alan Karp

[Brian Eaton]

On Sat, Mar 20, 2010 at 8:28 PM, Alan Karp <alan...@gmail.com> wrote:
> On Fri, Mar 19, 2010 at 11:19 AM, Brian Eaton <bea...@google.com> wrote:
>> On Fri, Mar 19, 2010 at 9:11 AM, Alan Karp <alan...@gmail.com> wrote:
>>> Since all requests go through the load balancer, that's the logical
>>> place to record the revocation.
>>
>> Load balancers don't typically operate at this level.
>>
> Good point.  Still, server farms usually have some (logically) shared
> storage, so any one of them can handle the revocation request and all
> will know about it.

Sure, if you assume you can do high-availability, low-latency,
replicated server-side state that can handle the same number of
queries per second as all of the services that rely on it, the problem
is easy. But that's not always practical.

Once deployments decide that they can't meet one of those assumptions,
they tend to turn towards cryptography to optimize in one direction or
another.

The result is protocols like Kerberos, or WRAP, or the SAML browser
POST profile, or OpenID.

Cheers,
Brian