Subject: [ogpx] Seed capability behavior

From: "Hurliman, John" <[email-masked]>
Date: Wed, 20 Jan 2010 15:16:54 -0700

The current handling of seed capabilities in Second Life is that they are treated like one time capabilities. The viewer knows a list of all of the capabilities it wants ahead of time, and makes a single request containing the full requested capabilities list. Are we mandating that VWRAP seedcaps must be one time capabilities or must not be one time capabilities? If it's up to each implementation, we'll get a situation where some clients make multiple requests to a seed cap and are incompatible with services that chose to implement one-time seedcaps.

John

---

From: David W Levine <[email-masked]>
Date: Wed, 20 Jan 2010 17:37:21 -0500

[email-masked] wrote on 01/20/2010 05:16:54 PM:

> [image removed] 
> 
> [ogpx] Seed capability behavior
> 
> Hurliman, John 
> 
> to:
> 
> [email-masked]
> 
> 01/20/2010 05:17 PM
> 
> Sent by:
> 
> [email-masked]
> 
> The current handling of seed capabilities in Second Life is that 
> they are treated like one time capabilities. The viewer knows a list
> of all of the capabilities it wants ahead of time, and makes a 
> single request containing the full requested capabilities list. Are 
> we mandating that VWRAP seedcaps must be one time capabilities or 
> must not be one time capabilities? If it’s up to each 
> implementation, we’ll get a situation where some clients make 
> multiple requests to a seed cap and are incompatible with services 
> that chose to implement one-time seedcaps.
> 
> John_______________________________________________
> ogpx mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx

My (fairly strong) preference is that they be persistent caps. I see no 
reason to force a client into the model of
asking for (and keeping track of) everything when it doesn't need it. 
Making it possible to pull caps as you need
them is upwards compatible with getting them all at once, and allows a 
more flexible usage.

I'd also point out that, if a service provides a "short term" cap which 
expires, we need a way to permit the client
to renew the cap, so that also strongly argues for a persistent cap, and, 
a fine grained one as well. I would
not want to force a re-get of every cap, when any single cap expired. 

- David 
~ Zha

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Wed, 20 Jan 2010 16:43:58 -0800

so... if the question is, "should the seed cap be a one shot or
persist?" then allow me to offer the following observations:

1. why having the seed cap being persistent is "good"

1.1. if the seed cap persists for a fixed period of time, the client
may request additional services from the seed cap later. it's possible
we may want to wait to issue service caps until the client actually
tries to do certain things (like spend money, transfer items,
inventory access, etc.)

1.2. if the seed cap persists for a fixed period of time, it allows
service caps to have shorter lifetimes. deployers may want some caps
(like caps for spending money and transferring items) to have a
shorter lifetime than others (like caps for connecting to public
regions or caps for getting the grid status.)

by persisting the seed cap, the client may request a new service cap
from the seed without having to re-authenticate.

2. why having the seed cap being persistent is "bad"

2.1. allowing the seed cap to persist introduces a "Time of Check,
Time of Use" vulnerability to the system. ( see
http://en.wikipedia.org/wiki/Time-of-check-to-time-of-use ). for
example, imagine that the agent domain's authority cancel's an account
after a seed cap is granted, but before it expires. the client will
still be able to request services with it.

--
   infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
         http://wiki.secondlife.com/wiki/User:Infinity_Linden

On Wed, Jan 20, 2010 at 14:37, David W Levine <[email-masked]> wrote:
> asking for (and keeping track of) everything when it doesn't need it. Making
> it possible to pull caps as you need
> them is upwards compatible with getting them all at once, and allows a more
> flexible usage.
>
> to renew the cap, so that also strongly argues for a persistent cap, and, a
> fine grained one as well. I would
> _______________________________________________
> ogpx mailing list
> [email-masked]

---

From: Hogmanay Milestone <[email-masked]>
Date: Wed, 20 Jan 2010 16:50:12 -0800 (PST)

----- Original Message ----
From: Infinity Linden (Meadhbh Hamrick) <[email-masked]>
To: David W Levine <[email-masked]>
Cc: [email-masked]; "[email-masked]" <[email-masked]>
Sent: Wed, January 20, 2010 4:43:58 PM
Subject: Re: [ogpx] Seed capability behavior

>tries to do certain things (like spend money, transfer items,

but how likely is this to happen?

>from the seed without having to re-authenticate.

you could request a "new seed" capability from the seed cap, then when you need a new one, you access the new seed capability to give you a new seed capability.

---

From: Hogmanay Milestone <[email-masked]>
Date: Wed, 20 Jan 2010 16:56:35 -0800 (PST)

>>you could request a "new seed" capability from the seed cap, then when you need a >new one, you access the new seed capability to give you a new seed capability.
>>
>>
>>
>
>how is this different from just keeping the seed cap around? if the concern is that an >attacker will be able to exploit a security vulnerability to access a seed cap, then it >could just as easily extract the "new seed" cap instead of the seed cap. the attacker >could then use the new seed cap  to get another seed cap, and the client is still pwnd.
 
but keeping the same seed cap would mean it's easier for someone to guess it.

---

From: Hogmanay Milestone <[email-masked]>
Date: Wed, 20 Jan 2010 16:58:26 -0800 (PST)

>
>
>the docs so far suggest that caps are 128 bit uuid's. if you're going to guess, you only
>have a 2^-128 chance of guessing correctly. by comparison, the chance that a gamma
>ray burst will cause a mass extinction event today is 2.7 * 10 ^ -12 (or about 2^-39) 

but caps are really more about delegation. you get a cap so you can delegate a privilege to a deputy.

---

From: Hogmanay Milestone <[email-masked]>
Date: Wed, 20 Jan 2010 16:59:35 -0800 (PST)

>are you suggesting that a client delegate service request to a third party?

yes, the client could request a seed cap using the username and password and give the seed cap to a proxy.

---

From: Hogmanay Milestone <[email-masked]>
Date: Wed, 20 Jan 2010 17:01:00 -0800 (PST)

>why? why not just make the proxy the client? 

because you would then need to give the proxy the client's username and password. bad!

---

From: Hogmanay Milestone <[email-masked]>
Date: Wed, 20 Jan 2010 17:03:42 -0800 (PST)

>but why would you need a proxy anyway? 

because the services requested by the proxy may be on the inside of a firewall while the client is on the outside. if the proxy was in the DMZ, you could use traditional network security tools to ensure that service requests only come from a proxy that you trust.

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Wed, 20 Jan 2010 17:16:55 -0800

> because the services requested by the proxy may be on the inside of a firewall while the client is on the outside. if the proxy was in the DMZ, you could use traditional network security tools to e…

so if i understand you correctly, you want the client out there on the
internet to authenticate to an agent domain, get a seed capability
from the agent domain and then pass that seed capability to a proxy in
the DMZ of some organization (say, like the client's employer.)

the proxy would then use that seed cap to request service caps from...
someone? the agent domain? or a server in the client's employer's
intranet (that the proxy can access because it's in the DMZ?)

it's unclear where you're requesting the service caps from.

but i think i understand why you want the seed cap to be a one-shot.
if it wasn't a one-shot, the proxy _could_ retain the ability to
request service caps on the client's behalf.

---

From: Hogmanay Milestone <[email-masked]>
Date: Wed, 20 Jan 2010 17:30:11 -0800 (PST)

yes. you don't want the proxy to retain the right (either by error or by malice) to request subordinate service caps from the agent domain or the sensitive service on the intranet.

if you assume that the client's enterprise has a trust relationship with the agent domain, the question of "who do you get the seed cap from" can go either way.

in one case, the client may authenticate to an "agent domain" managed by their enterprise using the password from their enterprise SSO solution. the "enterprise agent domain" may then contact a public agent domain through a different channel and retrieve a seed cap from the public agent domain. it (the enterprise agent domain) could then pass this seed cap on to the client.

or it could go the other way...

maybe you want the enterprise to be able to "bless" a user account defined in a public agent domain (like second life.) in this case, the client would authenticate to the public agent domain first. the public agent domain would then use some other technique to request a service caps from the enterprise agent domain, and would then pass them along to the client.

this would be a good use case if the enterprise wanted to grant privilege to existing accounts on a public agent domain instead of assuming the cost of provisioning a user account in their own domain.

---

From: Arrogant Cyberstar <[email-masked]>
Date: Wed, 20 Jan 2010 17:01:30 -0800

---

From: Arrogant Cyberstar <[email-masked]>
Date: Wed, 20 Jan 2010 17:00:06 -0800

---

From: Arrogant Cyberstar <[email-masked]>
Date: Wed, 20 Jan 2010 16:58:53 -0800

---

From: Arrogant Cyberstar <[email-masked]>
Date: Wed, 20 Jan 2010 16:57:15 -0800

On Wed, Jan 20, 2010 at 4:56 PM, Hogmanay Milestone <
[email-masked]> wrote:

> >>you could request a "new seed" capability from the seed cap, then when
> you need a >new one, you access the new seed capability to give you a new
> seed capability.
> >>
> >>
> >>
> >
> >how is this different from just keeping the seed cap around? if the
> concern is that an >attacker will be able to exploit a security
> vulnerability to access a seed cap, then it >could just as easily extract
> the "new seed" cap instead of the seed cap. the attacker >could then use the
> new seed cap  to get another seed cap, and the client is still pwnd.
>

the docs so far suggest that caps are 128 bit uuid's. if you're going to
guess, you only have a 2^-128 chance of guessing correctly. by comparison,
the chance that a gamma ray burst will cause a mass extinction event today
is 2.7 * 10 ^ -12 (or about 2^-39)

---

From: Arrogant Cyberstar <[email-masked]>
Date: Wed, 20 Jan 2010 16:53:27 -0800

On Wed, Jan 20, 2010 at 4:50 PM, Hogmanay Milestone <
[email-masked]> wrote:

> you could request a "new seed" capability from the seed cap, then when you
> need a new one, you access the new seed capability to give you a new seed
> capability.
>
>
how is this different from just keeping the seed cap around? if the concern
is that an attacker will be able to exploit a security vulnerability to
access a seed cap, then it could just as easily extract the "new seed" cap
instead of the seed cap. the attacker could then use the new seed cap  to
get another seed cap, and the client is still pwnd.