[cap-talk] Persistence as a cap value (was: Re: ...PLASH discussion)

[Jonathan S. Shapiro]

On Thu, 2008-03-13 at 12:45 -0400, Kevin Reid wrote:
> On Mar 13, 2008, at 11:55, Jonathan S. Shapiro wrote:
> 
> > In a networked capability system, a remote capability is generally
> > associated with an authenticated session. If the operation governed by
> > the capability motivates re-authentication on restart, it is entirely
> > sensible to revoke the cap. The problem is that you do not know who  
> > has
> > re-acquired control of the session, and to the session controller the
> > caps are merely data.
> >
> > But it's more efficient to simply revoke the session.
> 
> I'm trying to understand this, but having trouble with which party is  
> doing what. Which side of the network does the "session controller"  
> live on? What does "motivates re-authentication on restart" mean? Who  
> is "you" and why is the "session" apparently insecure?

Let me back up.

In practice, remote capabilities are data-only. As a practical matter,
what happens with the cryptographic capability during decryption is that
a locally protected data-only internal capability is formed that is
bound to a communication session to the remote machine.

Either the publishing machine or the client machine can sever the
session.

The reason that a session is insecure following restart is that the
publisher can no longer know who is sending packets from the other end.
This can sometimes be handled by cryptography, but note that
cryptographic sessions use non-durable symmetric keys that are generally
made to die (intentionally) when the participating node dies.

When this happens, there is either a mechanism to re-construct and
re-authenticate the session that existed between the machines, or more
commonly there is not. The need to reconstruct is actually good, because
the applications on the respective sides are no longer mutually
consistent following a failure.


shap