RE: Presence notification security - catching up

This seems as good a message to reply to as any on this issue...

Graham has identified the fundamental point here. We all agree, I think,
that RFC2778 does not describe a model in which entities other than
presentities generate notifications, and therefore any model in which an
intermediary (whether it's called a 'presence service' or not) does so is
not in our current scope. How we might then identify such intermediaries
(with a URI vs. a domainname) is a secondary question.

The argument that certain protocols (including some that aspire to be
CPIM-compliant) are not fully aligned with RFC2778 is probably not
compelling to this audience. All of the protocols that are required to be
CPIM-compliant undoubtedly have made some compromises in order to adhere to
the common architecture. I am also not persuaded on an initial reading that
the implementation problem described below is insurmountable.

No one here seems to doubt that the concept of an intermediary generating or
signing presence with some sort of identity certificate for an
administrative domain is potentially valuable. But many of us doubt, I
think, that we need to introduce this to CPIM in order to accomplish our
current tactical goal. Let's revisit this matter after we've completed our
initial CPIM work.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Sunday, August 25, 2002 4:01 PM
> To: Graham Klyne
> Cc: [email protected]
> Subject: 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]
> 



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