[cap-talk] mailkey: Is this broken ?? Identity key access?

[James A. Donald]

James A. Donald:
 >> He uses the key Alice gave him, to do stuff.  His
 >> identity key is also required.

Jed Donnelley wrote:
 > Ah!  Now maybe we're getting somewhere.  You say Bob's
 > identity key is also required?  So Bob must sign all
 > his requests?

Or he could get a transient cookie that enabled actions
to be billed to his account, or attributed to his
reputation, which is in practice the way things are
usually done.

Delegated capabilities make more sense in a geodesic
network than a star network, so when interacting with
Carol, or Carol's systems, he or his systems would
probably need to obtain a transient cookie that
identified him as Bob to Carol, but does not identify
him as Bob to anyone else, and when interacting with
Dave, a transient cookie that identified him as Bob to
Dave, but not to anyone else.

 > Doesn't that seem to suggest that every process acting
 > on Bob's behalf (e.g. the Solitaire program) must have
 > Bob's identity key?

The Solitaire program is not going to be on the network.
Let us assume instead the hearts program, since hearts
is a multiplayer game

I am pretty sure hearts does not have access to your
network logon, but it nonetheless manages.  I am not
sure how, but there are lots of ways.

Let us suppose we are writing a poker program and it is
important that persistent identities are truthfully
represented.  Let us suppose we are *really* worried
about security, and require that everyone who logs on to
the network, logs on with a smartcard that contains a
private key.  The logon server is, we suppose, trusted
to tell the truth.

Typically the logon server would send a secret, a strong
random number, a cookie, to each entity, encrypted to
that entities public key.  The entity knowing the
private key, would then know that secret, would then be
able to communicate with the logon server - and the
logon server would then know that the entity it was
communicating with was the holder of a particular public
key.

If each process acting on Bob's behalf knows that
cookie, not such a problem.  Even less of a problem if
each process acting on Bob's behalf knows a different
derived cookie, in this case a cookie that identifies
the poker program as "Bob's poker program"

If Bob should stick his smartcard into a trojaned
computer, the computer would then be able to act on his
behalf until he stuck his smartcard into another
computer, but no longer.

Of course, in practice, we are likely to use passwords,
in which case the (trusted) logon program knows the
public key of a logon server.  The logon server
identifies Bob through his human memorable password,
then we get a cookie as before, or possibly a transient
public/private key pair, which being transient need not
be strongly secured, plus for most purposes, a cookie
will suffice, and is indeed more convenient.

As with kerberos, if a Bob process wants identify itself
as a Bob process to a Carol process, then it could
request from the single signon server a symmetrically
encrypted token saying "This is Bob's poker process",
symmetricaly encrypted to the key that Carol's process
shares with the single signon server, thereby
establishing a key that Carol's poker program shares
with Bob's poker program, and only Bob's poker program,
and that each program knows it shares with the other.

Of course, this assumes some kind of single signon
service like kerberos, and in practice single signon
services have required more cooperation and coordination
than is usually forthcoming.

So perhaps in practice Bob will have to use his private
key to get a cookie with Alice, and use his private key
again to get another cookie with Carol, and again to get
another cookie with Dave - but all this requires is a
single program that knows his private key, rather than a
lot of programs that know his private key.  That program
then has ID cookies for all the people he is dealing
with, and produce per process pair ID cookies for all
the process pairs.

This is, on reflection, fairly complicated - but it is
also similar to what is in fact done today - in that ID
is represented by a transient cookie, using only table
lookup or symmetric encryption or both, and that right
now today, a single identity is represented by many
different cookies.

 > Which capabilities in Horton do you feel "represent a
 > great deal of information about identity"?  In Horton
 > capabilities can be labeled as the responsibility of
 > an identity (by a sealer ~= a public key).

A sealer sends signed messages - indeed signs
*arbitrary* messages - a fairly powerful capability, and
access to that capability needs to be fairly stringently
controlled.  We would prefer a process that signs rather
less general messages, for which access can be more
liberally granted - such as a process that merely
obtains transient identity cookies, and hands out
transient process specific identity cookies to processes
that its principal launched.

In the Horton pattern, you get a capability that
involves Carol signing that Alice has capability to
access something on Carol's system, and then Carol
signing, than Ann signed, that Bob ...

This involves a lot of access to these dangerously
powerful sealers, whose access must be severely
restricted.

  > If every executing program exercising permissions
 > that are Bob's responsibility must have access to
 > Bob's identity key, then it seems to me that you've
 > essentially got an ambient authority system.

Rather, every program launched by Bob on hardware he
controls gets access to evidence that can prove it is
the program that it is and was launched by Bob on
hardware he controls - but not access to a sealer that
is perfectly capable of signing  a message that Bob
agrees to pay five million dollars for real estate in
the middle of nowhere.

You can imagine this proposal implemented badly - and I
can with equal ease imagine horton implemented badly.

You will notice that none of the systems I describe have
the capability to sign anything - Carol can prove to
herself she got this message from Bob, but cannot prove
to Ann that the message came from Bob.

 > How do you handle the situation where two people are
 > asking a single program to act on their behalf with
 > permissions communicated from each?

You have imagined some system that as usual bears
absolutely no resemblance to anything I have proposed
doing something silly for reasons you have not
adequately explained.  Not being a mind reader, cannot
answer your question.

In my poker example, the programs were peer to peer, and
each peer had a shared key with each of the other peers
- if five players, each peer had four shared keys,
twenty keys in all, for each of the twenty possible
connections between five entities.