Re: Call for objections: subscription/notification security

Jonathan Rosenberg <[email protected]> writes:

> First off, authentication of subscriptions is something that I suspect 
> will not realistically happen with PKI signatures. The amount of cases 
> where users have public keys are small. 

The United States Government is an example of a large organization
that has a widely deployed Public Key Infrastructure.  Within the
United States Government are many groups that have requirements for
authenticated, non-reputable communication, and these groups must
communicate with each other.  It is unrealistic to expect that all of
these groups will acquire instant messaging software from one vendor.
If the IMPP working group fails to provide a standard means for
authenticated instant messaging and presence service, the government
will be forced to adopt propriety protocols that may not interoperate
well.  The use of propriety protocols will make in difficult for the
government to change vendors when a vendor offers an innovation.

While I have no direct knowledge of this fact, I find it hard to
believe that the United States Government is unique in its broad
deployment of PKI.  Surely other governments have done the same.
Independent governments are extremely unlikely to choose the same
vendor for IM software, which makes the need for a standard protocol
that much more important, and as you all know, this is an era in which
it is VERY important to enable authenticated government-to-government
communication.

In summary, the amount of cases where users have public keys must be
very large.  As security concerns grow, I expect that the population
of users with public keys will grow fast.

> This is much different from notifications, where I expect the presence 
> service to sign the presence document. Therefore, having a signed 
> notification is useful, and this is what CPIM provides.

I am very happy that we are in agreement over the need to allow the
signing of presence documents by presence services, however, CPIM
does not yet seem to provide the means to use the signed CPIM
documents effectively.

Any reasonable instant messaging client must be able to handle both
unsigned and signed notifications.  This means that there must be an
identifier in both an unsigned and signed notification that names the
presence service sending the information.  For signed documents, the
identifier must not also name a presentity, otherwise the owner of a
certificate that can be used to sign presence information can generate
a signed notification that fools its recipient into thinking that a
presence service sent the notification.

A client of presence service can use the name to determine its level
of trust in the service.  If the name is from a trusted source, the
client can require that notifications from this source be signed to
prevent spoofing.  An X.509 Version 3 Certificate can be used to bind
the name to the public key used to validate the signature.

Unlike the situation surrounding the addition of authenticated
subscriptions in which a common data format must be agreed to, it is
extremely simple to add support of effective use of signed presence
documents.  All one needs to do is to wrap PIDF documents with three
headers, a 'To' header that identifies the watcher of presence
information, a 'DateTime' header that time stamps the presence
information, and a 'From' header that identifies the presence server.

That's all it takes!  The now defunct CPIM version 02 document has a
place for this material reserved in Appendix B.  I'll write this
section if asked to do so.

> Finally, this group needs to finish. 

I can understand the reticence to adding a common subscription data
format to CPIM, but I see no reason to delay making the necessary
changes that allow effective use of signed presence information.  The
changes are quick and simple, so why wait?

John




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