RE: Sub/Not Security, Presence service identifiers

> When receiving a notification, a watcher would like to know that the
> presence service that is sending the notification is authorize to do
> so on behalf of the person that provided presence information.
> Without the authentication of the presence service, a watch could be
> spoofed into receiving presence information from an invalid source.

5.2.4 of RFC2779 says

   The protocol MUST provide means of protecting B from another
   PRINCIPAL C "spoofing" notification messages about B.

It is not otherwise specific about the mechanism to be used. I think one
approach could be to authenticate presence services, but (speaking as a
non-expert) I don't think that exhausts the space of possible ways to meet
the requirement.  I think the replay attack cited as an example could be
foiled by some form of timestamping.

I would appreciate a focus on this *requirement* and reasonable ways that we
can ensure that CPIM meets it, rather than narrowing prematurely to a
particular implementation and its characteristics.  [Unless we think that
presence-service authentication really is the only approach, in which case
we should say so explicitly somewhere.]

> One final point, I believe there is an explicit requirement in one of
> the RFC's that says a watcher has to be able to authenticate a
> presence service.  I'm too lazy to look it up now.

Pretty much all of the security requirements in 2779 are phrased in terms of
the ways that principals must be able to communicate or protected from one
another, not in terms of specific constraints on the entities between those
principals.

--Mark




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