Sub/Not Security, Presence service identifiers

In Yokohama, the idea that the subscription and notification operations
required some security services wasn't terribly popular. The arguments that
were raised against this security were familiar ones about PKI enrollment
and so on. It was moreover argued that the protocols that use CPIM can
supply these functions - that CPIM should only do the bare minimum to permit
interoperability, and that all other functions should be deferred to the
using protocol. The Security Considerations of the PIDF draft currently
support this perspective.

Given that, can a notify operation (or indeed any other CPIM message) be
authenticated after it has passed through a protocol gateway converting from
one CPIM-based protocol to another? If we think this should be possible,
then this security probably has to be staged within CPIM. This is similar to
the question of whether or not other security properties (like confidential
or integrity) should also be available through a CPIM gateway. Should I be
able to keep a CPIM message confidential from the operator of a CPIM
gateway, but still permit the ultimate recipient of the message to
understand it?

The requirements in RFC2779 (section 5) are very blunt about the
expectations of an IMPP service. There are a lot of statements to the effect
that protocols MUST have some means of supporting end-to-end AuthN,
confidentiality, integrity and so on, and these requirements are enumerated
for instant messages, notifications, and subscriptions. While RFC2779 has no
concept of CPIM gateways, it does have some very specific requirements (for
example, 5.2.1) about confidentiality that seem to suggest that a CPIM
gateway should not be able to read such messages.

Thoughts?

I also take it from recent list discussion that there is not a demonstrated
need for a presence service to have an explicit identifier in a notify
operation. Without security, such an identifier serves no purpose (it could
be trivially forged). With the identifier, it would be redundant with the
subjectAltName of an X.509 certificate that could be used to sign a
notification. Regardless of whether or not such an identifier is present,
the signature on the notification and the presentity should have some
reference integrity, but I don't see how this identifier helps with that.

Jon Peterson
NeuStar, Inc.



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