RE: On the need for presence service identifiers

> 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.

I think I understand this, and agree that it is a potential vulnerability. I
disagree about its likely practical importance and the proposed solution.

If I were particularly concerned about foiling this attack, I would change
the timestamps in the presence information to leases -- they would have a
start-time and an end-time, or a start-time and a duration. The presentity
could choose the length of lease so as to trade off the interval during
which this attack is possible vs. the inconvenience of refreshing
otherwise-unchanged presence information whose lease has expired.

I believe this approach would solve the identified problem without the need
to introduce the machinery to name, authenticate, etc. etc. the presence
services and individual notifications.  But I may have overlooked something,
so I'd welcome correction.

--Mark




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