Talk:Open Grid Protocol

Choosing an Agent

Round 1 : Choosing an Agent

The credential presented by the viewer may be valid for more than one agent.
If so, then the viewer must specify the agent it  wishes to control. If none is specified, 
and there are multiple possible agents, then log in will fail, and contain a list of possible agents. 
The viewer can then choose and reattempt login. 

That looks like a security hole, because it means that a person who gets login credentials now knows something they did not prove they knew before, namely the agent list. It should not include a list of agents, instead, an identifiable agent should be considered part of the credentials necessary for login.

Lillie Yifu 09:36, 22 August 2008 (PDT)

Round 2 : Agent Uniqueness is Checked After Account Authentication

Hey Lillie... sorry for taking so long to get back to this one...

If you look real close, you can see that the specification expects a compliant implementation to check for the multiple agent condition only after the account has been authenticated.

So... if you're a bad guy, you still have to know the account shared secret in order to get a list of agents on an account.

One "issue" with the specification is it's descriptive, not proscriptive. We don't define this as a requirement in the spec, because the spec defines stuff that flows over the wire. There are still interoperability profiles that will need to be hashed out, and defining that account authentication MUST occur before agent uniqueness is checked is one part of such an interoperability profile.

Infinity Linden 13:42, 6 October 2008(PDT)

Capability Lifetime

Round 1 : Capability Lifetime

Since cryptologically secure means the amount of time since creation to forge, break, or steal. Shouldn't all capabilities expire? Shouldn't there be a way of indicating when a capability is set to expire, so that clients of that capability can renew the lease on it? Also having capabilities with known numbers of uses is very valuable, so that clients could hand them out, confident that if they were overly broadly disseminated, the risk is limited to so many invocations, even if that number is a larger number.

Lillie Yifu 09:43, 22 August 2008 (PDT)

Round 2 : Leasing and Seed Caps

Hey Lillie... One thing to consider here is we don't want to introduce a TOCTOU (Time of Check, Time of Use) type vulnerability. Capabilities have a lifetime to ameliorate the TOCTOU ramifications implicit in capabilities. In other words, we don't (or at least shouldn't) do leasing on the capability's name, but on the permission it represents. In other words, if you have a capability named 'XXXXXXXX-XXXX-5XXX-XXXX-XXXXXXXXXXXX' which represents the right to rez your avatar in a given region, you don't want to renew that capability. Instead, what you _should_ do is request a new cap named 'YYYYYYYY-YYYY-5YYY-YYYY-YYYYYYYYYYYY' which represents the same thing, then expire the original cap. And... you should request this new capability using whatever authentication scheme you used to get the original cap. This way, if an untrusted third party happens to acquire the first cap, they won't have the ability to impersonate the agent indefinitely.

Now that i've said that... lemme run off to our simulator source and see if that's what we're actually doing.

With respect to caps with a wide number of uses... are you talking about seed caps? The expectation is that the seed cap is used just to get caps for other operations. We're expecting the viewer to get the list of subordinate caps once, then use those caps directly. In theory... after authenticating yourself to the agent domain and receiving the seed cap (which gives access to a list of subordinate caps), we could (and even should) expire the seed. That way, if a bad guy were able to get that seed, it would be expired by the time they could access it.

Again, we have the issue with the spec being descriptive rather than proscriptive. I'll see if I can add some text to upcoming drafts to either make it clear that this could / should be done, or write an interoperability profile that makes it more clear.

cheers, Infinity Linden 14:06, 6 October 2008 (PDT)