[ggf-ogsa-sec-wg] Re: Credential life time and looooong running jobs

[Frank Siebenlist <franks@mcs.anl.gov>]

At 08:18 AM 10/1/2002, Von Welch wrote:

>Seems to me that one thing makeing this very difficult is we don't
>have the kind of granularity yet for authorization assertions on the
>Grid that we do in the real world.
>
>When you give your broker an authorization assertion, it's very
>specific (e.g. "you can buy stock FOO if it drops below X in the next
>N days"). Today when you delegate on the Grid, it's impersonation with
>the only real restriction being lifetime. This is the equivalent of
>granting your stock broker a power of attorney, which I'm guessing you
>wouldn't be as comfortable with.
>
>What this gets at is that comfort level on credentials depends on the
>lifetime of the credentials and the capabilities greanted by the
>credentials. Lower the capabilities and you can up the lifetime.


Von, I hate to admit it, but you may be right.

But the interesting thing is that we've already seem to have accepted that 
we can extend lifetime of the authorization assertions beyond the lifetime 
of the credentials used to issue the assertion.

It becomes a "simple" policy decision, based on acceptable risk vs reward, 
how long we want the assertion to be valid.

-Frank.



>Frank Siebenlist writes (21:42 September 30, 2002):
>  > When I visited LBL last month, Tony and Mike pointed out that one of the
>  > issues with short-lived certificates issued by a kx509 service is that it
>  > would be difficult to use them for long running jobs.
>  >
>  > In other words, after the user's credentials have expired, you can not 
> have
>  > the job do anything on behalf of the user anymore.
>  >
>  > That observation kept bothering me, not only because Tony may be correct
>  > ;-), but also because it complicates the use of short-lived 
> credentials if
>  > you have to go to schemes where you would have to refresh them, or where
>  > you would be forced to use long-lived PKI-credentials.
>  >
>  > In the case of kx509, the life-time of the issued certificate is bound by
>  > the life-time of the kerberos ticket that was used to authenticate to the
>  > service, which is normally in the order of a working day or so.
>  > This would imply that authorization assertions can only be issued with a
>  > similar one day life span.
>  >
>  > At least that's what I thought it should be - however, I'm not sure if 
> that
>  > is true anymore.
>  >
>  > There are some real-life examples that show a different perspective:
>  >
>  > I can connect to my on-line banking, and instruct check payments and
>  > recurring payments to occur long after my login credentials have expired.
>  > The same is true for on-line brokers where I can give instructions to buy
>  > or sell stocks in the future if certain criteria are met.
>  >
>  > In our lingo: while my authentication credentials are valid, I issue an
>  > authorization assertion where I empower the service to do things on my
>  > behalf long after my authentication credentials have expired.
>  >
>  > How and why does that work?
>  >
>  > I can of course assert anything I want, and it's also up to the 
> service to
>  > honor that request.
>  > Is it because it is an event that can be audited?
>  > Is it enough to have a well recorded intent?
>  >
>  > Can we not do the same thing with normal short-lived Kerberos
>  > authentication credentials to issue long-lived authorization 
> assertions to
>  > a service to work on my behalf?
>  >
>  > How do we express that kind of policy to delegate and restrict these
>  > assertions?
>  >
>  > No answers from me here, just food for thought.
>  >
>  > -Frank.
>  >