Re: On the need for presence service identifiers

"Peterson, Jon" <[email protected]> writes:

> A couple of (slightly less amiable) notes below. I'm beginning to fear that
> this discussion is unlikely to bear fruit.

Maybe this will calm your fears.  Let's look at the big picture.  The
goal is to produce a protocol that meets the requirements outlined in
RFC 2779.  The requirement in focus is 5.2.4 of RFC 2779.

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

I have proposed an anti-spoofing mechanism that uses X.509 V3
Certificates, presence service identifiers, and notification content
that is timestamped and signed when a notification operation is
invoked.  If the protocol supports this mechanism, I believe we will
have a protocol that satisfies 5.2.4.

The requirement does not force implementors to protect a watcher from
being spoofed.  Implementors are free to provide no support for
digital signatures.  Furthermore, implementors are free to provide
some means of protecting a watcher against being spoofed even if the
mechanism contains known vulnerabilities.

For example, an implementation of the protocol could provide presence
services that distribute presence information that is signed by the
person that created the information, not by the services themselves.
Since this mechanism is vulnerable to the attack I will describe next,
this mechanism cannot be the only one allowed by the protocol, for it
would then not satisfy 5.2.4.

Assume Alice <pres:[email protected]> and Bob <pres:[email protected]>
communicate with each other via instant messaging.  On Sunday, both of
them publish presence information giving their inbox and stating their
inbox is closed.  Each individual signs and dates the information.

Eve subscribes to both Alice's and Bob's presentity and saves Sunday's
version of their presence information.  On Monday, either by playing
with DNS or by intercepting traffic between alice.com and bob.com, Eve
sends Bob's old presence information to Alice, and Alice's old
information to Bob.  Because of this, all day Monday, Alice and Bob
think each other is offline, and fail to communicate.  Alice and Bob
have no way of knowing that the presence information they have is
stale.  This attack is foiled if notification content is timestamped
and signed when a notification operation is invoked.

> If you mean here that end users (i.e. presentities) wouldn't be permitted to
> sign their own presence information, then your model directly violates
> RFC2778/RFC2779. This simply isn't acceptable.

I mean that sites using X.509 certificates can set up a policy that
restricts which certificates can be used to sign presence
notifications.  You don't get that kind of control otherwise.

John



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