Re: Presence notification security - catching up

Graham Klyne <[email protected]> writes:

> (d) there is debate about the trust model(s) to be supported, which
> might include: (i) endpoint presentity is trusted to sign
> notification, and/or (ii) a presence service acting on behalf of the
> endpoint presentity is trusted.

Please allow me to describe the debate as I see it from my
perspective.

This topic is about naming the people or services that sign requests
in an IMPP compliant instant messaging system.  One approach to doing
so is to perform a security analysis of the model given in RFC 2778.
Recall that a subject is a person or a service that applies operations
to objects, and possesses private keys.  For presence service, RFC
2778 identifies presentities and watchers as the things that "provide
information".  Therefore, presentities and watchers are the only
subjects, and only they can sign requests.  In this model, each
presentity has a unique subject name, but each presentity shares a
subject name with a watcher, so the name does not distinguish between
a watcher and a presentity.  Using the same subject name for more than
one subject can cause security problems.

The beauty of the model described in RFC 2778 is it places few
restrictions on software architectures that implement it.  Very
different systems can exchange information through gateways as long as
they adhere to the IMPP requirements.

Let me describe the architecture for the imaginary Acme Instant
Messaging system, AcmeIM, which is based on the PRIM and SIMP
architecture.  The AcmeIM system is designed to be IMPP compliant so
that one can easily construct a gateway between it and other IMPP
compliant systems.  It implements the model in RFC 2778, and uses
formats and identifiers as required.

An AcmeIM system has a single server associated with each domain name
that provides service.  The server is used to route instant messages,
store and distribute presence information, and manage subscriptions to
presentities.

People use a client to connect to a server.  A client sends instant
messages, sets the person's presence information, and requests
subscriptions to the person's buddies.  It also receives and displays
instant messages and presence information from other people.

A client connects to one server.  Server-to-server connections are
used to transfer information between domains.

AcmeIM authenticates all requests using digital signatures.  A
person's client is used to sign instant messages, presence information
updates, and subscription requests.  The server is used to sign all
notifications about presence information stored on the server when it
is distributed.  In short, people sign instant messages, presence
updates, and subscription requests, and servers sign notification
requests.

I trust you can see that one can write gateways to other IMPP
compliant systems for the AcmeIM architecture, as described so far.
The trouble comes when a user on a non-AcmeIM system wants to be sure
that a signed request from an AcmeIM subject was signed using a
private key that is owned by that subject.

X.509 V3 Certificates can be used to give the non-AcmeIM user the
assurance they require.  Suppose AcmeIM user John Doe has an inbox
identified by im:[email protected], and a presentity identified by
pres:[email protected].  It is natural to issue John Doe a certificate
that gives him two alternate names, URI:im:[email protected], and
URI:pres:[email protected].  The non-AcmeIM user knows that a
subscription request with a watcher attribute of 'pres:[email protected]'
comes from the correct subject because the attached certificate
includes URI:pres:[email protected] as an alternate name.

To sign notifications, it is natural to issue the server at widget.com
a certificate that gives it one alternate name, the presence set
identifier URI:pres:widget.com.  The non-AcmeIM user knows that a
notification request with a target attribute of 'pres:[email protected]'
comes from the correct subject because the attached certificate
includes URI:pres:widget.com as an alternate name.

The presentity set identifier is needed because AcmeIM subjects do not
map one-to-one to the subjects one derives from a security analysis of
the model in RFC 2778.  If we require that all instant messaging
implementations use only the subject names from RFC 2778, we will
impose an odd constraint on the AcmeIM architecture.  The server would
be required to maintain a private key and a certificate for every
presentity for which it stores presence information.

Up until now, the RFC 2778 model has placed few unnatural restrictions
on implementations, however, this will be the result if we force
implementations to use subject names that fail to correspond to the
subjects that exist in an actual implementation.

John



  [reminder: [email protected] for non-technical discussions, please]