[cap-talk] Session failures (was: Re: Persistence as a cap value)

[Jed Donnelley]

At 10:07 AM 3/13/2008, Jonathan S. Shapiro wrote:
>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.

The above makes sense to me.  However, I wonder that you seem to
suggest this situation is unique to (or associated with?) the
distributed capability context?  It seems to me the same
situation can arise in a local context.  At any time any
process could fail (e.g. an internal software inconsistency,
or perhaps due to some externality) and this could result
in the same sort of 'session' failure.  From my perspective
such failures is just something that appropriate defensive
programming must always deal with.  I have found it one of
the more challenging aspects of programming (e.g. generating
appropriate test cases), but it seems to me a necessary part
of the job.

--Jed  http://www.webstart.com/jed-signature.html