Notification authentication in CPIM (Summary)

Enclosed is a summary of the messages sent on the subject
"Notification authentication in CPIM".

In secure systems, it is important to be able to authenticate the
principal that issues a request.  A request can be authenticated using
a digital signature.  The owner of the private key used to sign a
request identifies the principal.

For an instant message, the client that is used to send a message
originates a send message request, and the client can use its owner's
private key to sign the send message request.  Clients also originate
subscription requests.

Presence servers originate notification requests.  Therefore, they
must have the ability to sign notification requests.  Otherwise,
people with bad intent can send false presence information to a
client, and spoof it into thinking it came from the real source.

The CPIM Message Format allows authenticated instant messages in which
the principal's public key is attached as an X.509 V3 Certificate.  An
important question is this: is the owner of the private key allowed to
use and access the instant inbox identified in the 'From' header of
the signed send message request?  In other words, how does the
receiver know that a reply will go to the right principal?

Secure systems make this decision based on the certificate.  If the
Subject Alternative Names of the certificate contains the URI of the
instant inbox in the 'From' header of the request, than clients that
receive the message may assume the originator is allowed to use this
inbox.

Receivers of notifications require the same assurance.  They need to
know that the signer of a notification is allowed to send a
notification from a given presence server.  I propose that this be
done as it is for instant messaging.  When signing a notification, a
PIDF document should be wrapped with three headers, a 'To' header
giving the target of the notification request, a 'Datetime' header to
avoid replay, and a 'From' header used to identify the presence
server.  The document can be signed as is an instant message.

A presence server can be identified by Presence URI, however, it is
important that that URI does not identify a presentity.  A certificate
with a Subject Alternative Name that contains the name of a presentity
should be used only by a client that is submitting content to the
presentity, in other words, a client, not the presence server.  If a
presence server put an identifier for a presentity in the 'From'
header, the client that can submit content can also masquerade as the
server, and therefore spoof a client.

A wrapped notification might look like:

Content-type: Message/CPIM

To: pres:client@laptop
From: pres:server@rack
Datetime: 2002-07-18T13:38:22-8:00

Content-type: application/cpim-pdif+xml	

..................

In the SIMP 1.4 Protocol, there is a distinguished user 'notifier'
that is used to identify a presence server, and clients are forbidden
from logging in with that user name.  This is how SIMP distinguishes
messages originated from servers from those issued by clients.

John





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